H. Peter Anvin wrote:

>> Also when /home or other important fs are mounted via autofs there is
>> not much practical difference between a hung kernel and a hung
>> daemon. You have to reboot the system anyways.
> 
> 
> a) Guess which one is easier to debug?

When they may both equally hang your machine, neither.

> b) Do people around here really believe that putting things in the 
> kernel magically makes them work right?
> 

No magic involved.

When atomicity is needed wrt. mountpoints, moving the logic into the 
kernel is a much simpler solution.

How much code was required to handle the corner cases and races in the 
existing autofs implementations?

To put it into perspective, the I'm calling for the following major changes:

1) move expiry logic out of autofs and into the VFS where others can use 
it and notice when it breaks when VFS internals change.  For example, I 
just noticed that autofs4 in 2.6 hasn't been updated to grab the new 
vfsmount_lock instead of dcache_lock in certain circumstances.

2) move the loop that used to spin around and ask kernelspace if there 
was anything to expire into the VFS as well, where it won't be killed.

3) introduce some way to let userspace walk the mountpoints using file 
descriptors as references.

4) figure out a way to get super_blocks to clone so that we can have 
some consistent automount functionality across cloned namespaces.

(1) and (2) shouldn't be hard at all to do considering David Howells has 
done the majority of this already. (3) is needed in order to manage 
direct mounts properly for when they are 'covered'.  Admittedly, (4) 
comes off as an ugly hack.

Also, (2) was the only 'active' task the automount daemon was doing. 
Everything else it did can be rewritten in the form of a usermode helper 
that runs only when it is needed.  This simplifies the userspace code a lot.


-- 
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~