summaryrefslogtreecommitdiff
path: root/fs/gfs2/ops_dentry.c
diff options
context:
space:
mode:
authorIan Kent <raven@themaw.net>2007-08-23 01:01:54 +0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-08-23 06:52:46 +0400
commit1864f7bd58351732593def024e73eca1f75bc352 (patch)
treebe7f048f3a41b257ece24805aa96453b81c78349 /fs/gfs2/ops_dentry.c
parentf4768ffd1d4b7b07ae2c4c3d93c9f99cd68e996c (diff)
downloadlinux-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