Re: Potential regression after fsnotify_nameremove() rework in 5.3

[Amir Goldstein <amir73il@gmail.com>]

On Sat, Jan 15, 2022 at 5:11 AM Ivan Delalande <colona@arista.com> wrote:
>
> Hi,
>
> Sorry to bring this up so late but we might have found a regression
> introduced by your "Sort out fsnotify_nameremove() mess" patch series
> merged in 5.3 (116b9731ad76..7377f5bec133), and that can still be
> reproduced on v5.16.
>
> Some of our processes use inotify to watch for IN_DELETE events (for
> files on tmpfs mostly), and relied on the fact that once such events are
> received, the files they refer to have actually been unlinked and can't
> be open/read. So if and once open() succeeds then it is a new version of
> the file that has been recreated with new content.
>
> This was true and working reliably before 5.3, but changed after
> 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
> d_delete()") specifically. There is now a time window where a process
> receiving one of those IN_DELETE events may still be able to open the
> file and read its old content before it's really unlinked from the FS.

This is a bit surprising to me.
Do you have a reproducer?

>
> I'm not very familiar with the VFS and fsnotify internals, would you
> consider this a regression, or was there never any intentional guarantee
> for that behavior and it's best we work around this change in userspace?

It may be a regression if applications depend on behavior that changed,
but if are open for changes in your application please describe in more details
what it tries to accomplish using IN_DELETE and the ekernel your application
is running on and then I may be able to recommend a more reliable method.

Thanks,
Amir.