Hi,
I am wondering if this is a known issue, but I just built the current git

and several autofs mounts mysteriously disappeared. Restarting autofs could

fix some, but then lose others. 2.6.22 was fine.
Is there anything I could check other than bisect? (It may take some time

for me to get to it)
Thanks for your help.
Hua
-

the commit below is the only autofs4 patch that went into the git tree

since 2.6.22.
cu

Adrian
commit 1864f7bd58351732593def024e73eca1f75bc352

Author: Ian Kent <raven@themaw.net>

Date:   Wed Aug 22 14:01:54 2007 -0700
    autofs4: deadlock during create
    Due to inconsistent locking in the VFS between calls to lookup and

    revalidate deadlock can occur in the automounter.
    The inconsistency is that the directory inode mutex is held for both lookup

    and revalidate calls when called via lookup_hash whereas it is held only

    for lookup during a path walk.  Consequently, if the mutex is held during a

    call to revalidate autofs4 can't release the mutex to callback the daemon

    as it can't know whether it owns the mutex.
    This situation happens when a process tries to create a directory within an

    automount and a second process also tries to create the same directory

    between the lookup and the mkdir.  Since the first process has dropped the

    mutex for the daemon callback, the second process takes it during

    revalidate leading to deadlock between the autofs daemon and the second

    process when the daemon tries to create the mount point directory.
    After spending quite a bit of time trying to resolve this on more than one

    occassion, using rather complex and ulgy approaches, it turns out that just

    delaying the hashing of the dentry until the create operation works fine.
    Signed-off-by: Ian Kent <raven@themaw.net>

    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c

index 2d4c8a3..45ff3d6 100644

--- a/fs/autofs4/root.c

+++ b/fs/autofs4/root.c

@@ -587,19 +587,20 @@ static struct dentry *autofs4_lookup(struct inode *dir, struct dentry *dentry, s

 	unhashed = autofs4_lookup_unhashed(sbi, dentry->d_parent, &dentry->d_name);

 	if (!unhashed) {

...
[ message continues ]

Maybe but there is an NFS change that appears to be in the current

2.6.23-rc kernel and doesn't seem to be in 2.6.22 that is known to break

some autofs maps and also breaks amd.
I can't seem to locate the commit just now.

In the meantime what version of user space autofs and nfs-utils are you

running?

And can you post your autofs maps please?
Ian
-

I am in the process of bisecting now. It takes a while but the bad commit is

between 2.6.22 and 13f9966b3ba5b45f47f2ea0eb0a90afceedfbb1f (June 28). I'll

continue tomorrow.
My system is FC4. 
autofs-4.1.4-26

nfs-utils-1.0.7-13.FC4
By the way, the particular autofs commit Andrian sent is innocent. It's

something else.
It will still take me about 10 reboots to bisect. If anyone has a patch for
-

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...
This (and it's related patches) may be the problem.

I can probably tell if you post your map or if you strace the automount

process managing the a problem mount point and look for mount returning
-