summaryrefslogtreecommitdiffstats
path: root/drivers/char
diff options
context:
space:
mode:
authorAndreas Gruenbacher <agruen@suse.de>2007-02-12 00:51:47 -0800
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-02-12 09:48:27 -0800
commiteb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1 (patch)
tree9b35fa3ac8cb3d6fc4eb74d83d15f0f929f54631 /drivers/char
parent5c3bd438ccb94f5d5bf5d8711330e038dc8dd21b (diff)
downloadop-kernel-dev-eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1.zip
op-kernel-dev-eb3dfb0cb1f4a44e2d0553f89514ce9f2a9fcaf1.tar.gz
[PATCH] Fix d_path for lazy unmounts
Here is a bugfix to d_path. First, when d_path() hits a lazily unmounted mount point, it tries to prepend the name of the lazily unmounted dentry to the path name. It gets this wrong, and also overwrites the slash that separates the name from the following pathname component. This is demonstrated by the attached test case, which prints "getcwd returned d_path-bugsubdir" with the bug. The correct result would be "getcwd returned d_path-bug/subdir". It could be argued that the name of the root dentry should not be part of the result of d_path in the first place. On the other hand, what the unconnected namespace was once reachable as may provide some useful hints to users, and so that seems okay. Second, it isn't always possible to tell from the __d_path result whether the specified root and rootmnt (i.e., the chroot) was reached: lazy unmounts of bind mounts will produce a path that does start with a non-slash so we can tell from that, but other lazy unmounts will produce a path that starts with a slash, just like "ordinary" paths. The attached patch cleans up __d_path() to fix the bug with overlapping pathname components. It also adds a @fail_deleted argument, which allows to get rid of some of the mess in sys_getcwd(). Grabbing the dcache_lock can then also be moved into __d_path(). The patch also makes sure that paths will only start with a slash for paths which are connected to the root and rootmnt. The @fail_deleted argument could be added to d_path() as well: this would allow callers to recognize deleted files, without having to resort to the ambiguous check for the " (deleted)" string at the end of the pathnames. This is not currently done, but it might be worthwhile. Signed-off-by: Andreas Gruenbacher <agruen@suse.de> Cc: Neil Brown <neilb@suse.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/char')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud