On 2012-05-28, at 11:33 AM, Theodore Ts'o wrote:
> If we rmdir a directory which is a hard link to '.', we will deadlock
> trying to grab the directory's i_mutex. Check for this condition and
> return EINVAL, which is what we return if the user attempts to rmdir
> "/foo/bar/."
>
> Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
> ---
> fs/namei.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 0062dd1..081f872 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2774,6 +2774,17 @@ static long do_rmdir(int dfd, const char __user *pathname)
> error = -ENOENT;
> goto exit3;
> }
> + if (nd.path.dentry->d_inode == dentry->d_inode) {
> + /*
> + * Corrupt file system where there is a symlink to
> + * '.'; treat it as if we are trying to rmdir '.'
> + *
> + * XXX Should we call into the low-level file system
> + * to request that the file system be marked corrupt?
> + */
> + error = -EINVAL;
> + goto exit3;
> + }
> error = mnt_want_write(nd.path.mnt);
> if (error)
> goto exit3;
This patch is good from the POV of covering all filesystems, and
avoiding the deadlock at the dcache level. It would be possible to
detect this problem in the filesystem itself during lookup, before
the bad link got into the dcache itself. Something like:
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 349d7b3..4a9c99d 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -1037,6 +1037,12 @@ static struct dentry *ext4_lookup(struct inode
EXT4_ERROR_INODE(dir, "bad inode number: %u", ino);
return ERR_PTR(-EIO);
}
+ if (ino == dir->i_ino) {
+ EXT4_ERROR_INODE(dir, "'%.*s' linked to parent dir",
+ dentry->d_name.len,
+ dentry->d_name.name);
+ return ERR_PTR(-EIO);
+ }
inode = ext4_iget(dir->i_sb, ino);
if (inode == ERR_PTR(-ESTALE)) {
EXT4_ERROR_INODE(dir,
Though -EIO could be replaced with -EBADF or -ELOOP, or something else.
Cheers, Andreas
--
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
