Hi,
I am writing a kernel module to extend a file system.
Given a pathname, my kernel module tried to call
do_path_lookup(AT_FDCWD, pathname, 0, nd);
and then call path_release(nd) to release nameidata structure.
However, my file system module frequently crashed after I added the
above two lines of code.
I traced the execution and found that if the pathname is a special
file (sock, block, char, etc),
the nd->mnt->mnt_count is not increased. But when I do path_release(),
nd->mnt->mnt_count will be reduced by one. If I ran into special files
for several times, the mnt_count can be reduced to 0!. That makes the
file system thought that the file system should be umounted and then
it destroys the active inodes and dentries. This caused the following
file system operations to fail.
An nasty solution is of course to identify the file type and then
determine whether to call path_release(). But this does not seems to
be a elegant solution.
Is someone familiar with this part of code? Why doesn't
do_path_lookup() increase the mnt_count?
I found the following code in fs/open.c: sys_faccessat()
res = __user_walk_fd(dfd, filename, LOOKUP_FOLLOW|LOOKUP_ACCESS, &nd);
if (!res) {
res = vfs_permission(&nd, mode);
/* SuS v2 requires we report a read only fs too */
if(!res && (mode & S_IWOTH) && IS_RDONLY(nd.dentry->d_inode)
&& !special_file(nd.dentry->d_inode->i_mode))
res = -EROFS;
path_release(&nd);
}
In this code, it seems to call path_release() anyway, no matter which
type the target file is. Why didn't this code cause trouble?
Any help is highly appreciated!
-x
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
