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.
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?
Thanks a lot,
--
Ivan Delalande
Arista Networks
