Forcefully unmounting devfs...

[Scott Long]

Poul-Henning Kamp wrote:

> In message <200412212029.iBLKT05S044869 at beastie.mckusick.com>, Kirk McKusick wr
> ites:
> 
> 
>>Poul-Henning is correct. To elaborate, the operations vector for device
>>vnodes have historivcally been built up from a mix of specfs opertions
>>which deal with the mechanics of doing I/O (read, write, strategy, ioctl,
>>etc) and the containing filesystem (UFS, NFS) operations for naming (open,
>>stat, chown, chmod, rename, etc). When the containing filesystem is
>>forcibly unmounted, the naming operations are stripped away leaving
>>only the I/O operations. Thus read, write, strategy, and such continue
>>to work, but name related operations on the descriptor (fstat, fchown,
>>fchmod, etc) will fail as the underlying naming operations are gone. 
>>I still believe that this is a reasonable approach as it lets things
>>like the disk continue to operate when an unmount is done.
> 
> 
> But the question in my mind is: do we really want disks/devices to
> continue working if we forcefully unmount a devfs instance ?
> 
> Today, the main if not only use for multiple devfs instances are
> chroot/jail, and if I wear my jail-warden uniform for a moment, I
> would expect that a forceful unmount of /some/jail/dev would mean
> "just kill anything that prevents me from doing a normal umount
> of this devfs instance".
> 
> Problem with that is that we get into cascading forced unmounts,
> which I in my jail warden outfit would love to just Do The Right Thing,
> but as a kernel hacker I know how many panics are just waiting for
> that to happen...
> 
> So as I see it, we have to possible ways it can work:
> 
> Either disable forceful unmount of devfs, which makes sense from
> KISS and many other principles, and then jail wardens will have to
> find other ways to clean up their jails
> 
> Or make forceful unmounts kill any process which holds it busy,
> unmount any filesystem using a device from it and then clean
> up and leave.
> 
> The one option I don't like is:  unmount and leave all sorts of stuff
> in weird intermediate states from which the administrator may not
> be able to recover.
> 
> The more I think about it, the more I lean towards the first option.
> 

I think that I'd agree here from the point of view of finding an 
expedient way to keep from shooting off feet.

Scott