On Thu 16-07-20 16:54:08, Amir Goldstein wrote:
> On Thu, Jul 16, 2020 at 4:29 PM Jan Kara <jack@xxxxxxx> wrote:
> >
> > On Thu 16-07-20 15:13:11, Jan Kara wrote:
> > > On Thu 16-07-20 11:42:24, Amir Goldstein wrote:
> > > > Remove the unneeded check for positive source dentry in
> > > > fsnotify_move().
> > > >
> > > > fsnotify_move() hook is mostly called from vfs_rename() under
> > > > lock_rename() and vfs_rename() starts with may_delete() test that
> > > > verifies positive source dentry. The only other caller of
> > > > fsnotify_move() - debugfs_rename() also verifies positive source.
> > > >
> > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
> > >
> > > But in vfs_rename() if RENAME_EXCHANGE is set and target is NULL,
> > > new_dentry can be negative when calling fsnotify_move() AFAICT, cannot it?
> >
> > FWIW, renameat2() doesn't allow RENAME_EXCHANGE with non-existent target
> > and I didn't find any other place that could call vfs_rename() with
> > RENAME_EXCHANGE and negative target but still vfs_rename() seems to support
> > that and so fsnotify should likely handle that as well.
>
> If some code did call vfs_rename() like that d_exchange() will barf:
>
> void d_exchange(struct dentry *dentry1, struct dentry *dentry2)
> {
> write_seqlock(&rename_lock);
>
> WARN_ON(!dentry1->d_inode);
> WARN_ON(!dentry2->d_inode);
Good point. Thanks for explanation!
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
