All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Ted Tso <tytso@mit.edu>,
	linux-ext4@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] ext4: Fix possible corruption when moving a directory
Date: Tue, 16 May 2023 21:58:36 -0700	[thread overview]
Message-ID: <20230517045836.GA11594@frogsfrogsfrogs> (raw)
In-Reply-To: <20230126112221.11866-1-jack@suse.cz>

On Thu, Jan 26, 2023 at 12:22:21PM +0100, Jan Kara wrote:
> When we are renaming a directory to a different directory, we need to
> update '..' entry in the moved directory. However nothing prevents moved
> directory from being modified and even converted from the inline format
> to the normal format. When such race happens the rename code gets
> confused and we crash. Fix the problem by locking the moved directory.

Four months later, I have a question --

Is it necessary for ext4_cross_rename to inode_lock_nested on both
old.inode and new.inode?  We're resetting the dotdot entries on both
children in that case, which means that we also need to lock out inline
data conversions, right?

--D

> CC: stable@vger.kernel.org
> Fixes: 32f7f22c0b52 ("ext4: let ext4_rename handle inline dir")
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
>  fs/ext4/namei.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index dd28453d6ea3..270fbcba75b6 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -3872,9 +3872,16 @@ static int ext4_rename(struct user_namespace *mnt_userns, struct inode *old_dir,
>  			if (new.dir != old.dir && EXT4_DIR_LINK_MAX(new.dir))
>  				goto end_rename;
>  		}
> +		/*
> +		 * We need to protect against old.inode directory getting
> +		 * converted from inline directory format into a normal one.
> +		 */
> +		inode_lock_nested(old.inode, I_MUTEX_NONDIR2);
>  		retval = ext4_rename_dir_prepare(handle, &old);
> -		if (retval)
> +		if (retval) {
> +			inode_unlock(old.inode);
>  			goto end_rename;
> +		}
>  	}
>  	/*
>  	 * If we're renaming a file within an inline_data dir and adding or
> @@ -4006,6 +4013,8 @@ static int ext4_rename(struct user_namespace *mnt_userns, struct inode *old_dir,
>  	} else {
>  		ext4_journal_stop(handle);
>  	}
> +	if (old.dir_bh)
> +		inode_unlock(old.inode);
>  release_bh:
>  	brelse(old.dir_bh);
>  	brelse(old.bh);
> -- 
> 2.35.3
> 

  parent reply	other threads:[~2023-05-17  4:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-26 11:22 [PATCH] ext4: Fix possible corruption when moving a directory Jan Kara
2023-02-19  5:40 ` Theodore Ts'o
2023-05-17  4:58 ` Darrick J. Wong [this message]
2023-05-23 10:46   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230517045836.GA11594@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.