On Mon, Jan 24, 2022 at 3:50 PM Jan Kara <jack@xxxxxxx> wrote:
>
> On Thu 20-01-22 23:53:04, Amir Goldstein wrote:
> > Apparently, there are some applications that use IN_DELETE event as an
> > invalidation mechanism and expect that if they try to open a file with
> > the name reported with the delete event, that it should not contain the
> > content of the deleted file.
> >
> > Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
> > d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
> > will have access to a positive dentry.
> >
> > This allowed a race where opening the deleted file via cached dentry
> > is now possible after receiving the IN_DELETE event.
> >
> > To fix the regression, create a new hook fsnotify_delete() that takes
> > the unlinked inode as an argument and use a helper d_delete_notify() to
> > pin the inode, so we can pass it to fsnotify_delete() after d_delete().
> >
> > Backporting hint: this regression is from v5.3. Although patch will
> > apply with only trivial conflicts to v5.4 and v5.10, it won't build,
> > because fsnotify_delete() implementation is different in each of those
> > versions (see fsnotify_link()).
> >
> > A follow up patch will fix the fsnotify_unlink/rmdir() calls in pseudo
> > filesystem that do not need to call d_delete().
> >
> > Reported-by: Ivan Delalande <colona@xxxxxxxxxx>
> > Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/
> > Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
> > Cc: stable@xxxxxxxxxxxxxxx # v5.3+
> > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>
> Thanks. Both patches look good to me now, I've merged them into my tree and
> will push them to Linus later this week.
LTP test:
https://github.com/amir73il/ltp/commits/in_delete
I'll post it later.
Thanks,
Amir.
