Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 23 May 2023 12:46:44 +0200
From:   Jan Kara <jack@suse.cz>
To:     "Darrick J. Wong" <djwong@kernel.org>
Cc:     Jan Kara <jack@suse.cz>, 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
Message-ID: <20230523104644.dgvmjq4xzhemlpbm@quack3>
References: <20230126112221.11866-1-jack@suse.cz>
 <20230517045836.GA11594@frogsfrogsfrogs>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230517045836.GA11594@frogsfrogsfrogs>
Precedence: bulk

On Tue 16-05-23 21:58:36, Darrick J. Wong wrote:
> 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?

Ouch, you're right. In that path we need to lock both source & target
directories since lock_two_nondirectories() call in vfs_rename() will not
lock them... I'll send a patch. Thanks for spotting this!

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR