diff options
author | Ian Kent <raven@themaw.net> | 2007-08-23 01:01:54 +0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-08-23 06:52:46 +0400 |
commit | 1864f7bd58351732593def024e73eca1f75bc352 (patch) | |
tree | be7f048f3a41b257ece24805aa96453b81c78349 /fs/gfs2/ops_dentry.c | |
parent | f4768ffd1d4b7b07ae2c4c3d93c9f99cd68e996c (diff) | |
download | linux-1864f7bd58351732593def024e73eca1f75bc352.tar.xz |
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>
Diffstat (limited to 'fs/gfs2/ops_dentry.c')
0 files changed, 0 insertions, 0 deletions