summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorIan Kent <raven@themaw.net>2007-08-22 14:01:54 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-08-22 19:52:46 -0700
commit1864f7bd58351732593def024e73eca1f75bc352 (patch)
treebe7f048f3a41b257ece24805aa96453b81c78349 /kernel
parentf4768ffd1d4b7b07ae2c4c3d93c9f99cd68e996c (diff)
downloadop-kernel-dev-1864f7bd58351732593def024e73eca1f75bc352.zip
op-kernel-dev-1864f7bd58351732593def024e73eca1f75bc352.tar.gz
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 'kernel')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud