summaryrefslogtreecommitdiff
path: root/arch/arm/mach-kirkwood/Kconfig
diff options
context:
space:
mode:
authorLino Sanfilippo <linosanfilippo@gmx.de>2010-07-15 17:11:55 +0400
committerTyler Hicks <tyhicks@linux.vnet.ibm.com>2010-08-09 22:42:12 +0400
commit21edad32205e97dc7ccb81a85234c77e760364c8 (patch)
treed68f20aa288a6fe98547fe348d3c300020ad8daf /arch/arm/mach-kirkwood/Kconfig
parentceeab92971e8af05c1e81a4ff2c271124b55bb9b (diff)
downloadlinux-21edad32205e97dc7ccb81a85234c77e760364c8.tar.xz
ecryptfs: dont call lookup_one_len to avoid NULL nameidata
I have encountered the same problem that Eric Sandeen described in this post http://lkml.org/lkml/fancy/2010/4/23/467 while experimenting with stackable filesystems. The reason seems to be that ecryptfs calls lookup_one_len() to get the lower dentry, which in turn calls the lower parent dirs d_revalidate() with a NULL nameidata object. If ecryptfs is the underlaying filesystem, the NULL pointer dereference occurs, since ecryptfs is not prepared to handle a NULL nameidata. I know that this cant happen any more, since it is no longer allowed to mount ecryptfs upon itself. But maybe this patch it useful nevertheless, since the problem would still apply for an underlaying filesystem that implements d_revalidate() and is not prepared to handle a NULL nameidata (I dont know if there actually is such a fs). With this patch (against 2.6.35-rc5) ecryptfs uses the vfs_lookup_path() function instead of lookup_one_len() which ensures that the nameidata passed to the lower filesystems d_revalidate(). Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de> Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Diffstat (limited to 'arch/arm/mach-kirkwood/Kconfig')
0 files changed, 0 insertions, 0 deletions