Re: [BUG] fanotify: destroy/add race leaves a mark on a detached connector

[Christian Brauner]

On Mon, Oct 12, 2026 at 03:26:59PM +0200, Amir Goldstein wrote:
> On Mon, Oct 12, 2026 at 1:48 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > On Thu, Sep 3, 2026 at 3:07 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> > >
> > > On Wed, Sep 2, 2026 at 11:51 PM Daehyeon Ko <4ncienth@xxxxxxxxx> wrote:
> > > >
> > > > Hi Amir,
> > > >
> > > > I was able to make the handle-reopen sequence reliable on ext4 and drafted
> > > > an LTP test for it.
> > > >
> > > > The test keeps 120 auxiliary inode marks on the victim to widen the interval
> > > > after the first FAN_DELETE_SELF, pins the unlink and handle-reopen workers to
> > > > different CPUs, and has the reopen worker read the event queue nonblocking
> > > > before calling open_by_handle_at().
> > > >
> > > > I ran the exact final test for 100 iterations in each of two fresh 2-vCPU
> > > > KASAN boots per kernel:
> > > >
> > > >   - unmodified v7.2: 200/200 iterations reopened the unlinked inode, and
> > > >     closing the reopened fd generated a second FAN_DELETE_SELF;
> > > >   - v7.2 with your patch: 200/200 iterations returned ESTALE from
> > > >     open_by_handle_at(), with no duplicate FAN_DELETE_SELF.
> > > >
> > > > The test is based on LTP master commit
> > > > 12724413534a6d4160ff9694ba6f09daa4ccb6bd. The attached patch adds
> > > > fanotify26 and the corresponding build and runtest entries.
> > >
> > > Very nice!
> > >
> > > I think we should wait for Christian to pick up the fix or suggest an
> > > alternative, but after that please post this test to LTP.
> > >
> > > Thanks for following up on this!
> >
> > Christian,
> >
> > Please apply this attached patch in-place of 669bb5af15d41 ("fs: make
> > sure to call fsnotify_inoderemove() only once when inode is dead") on
> > your vfs-7.4.misc branch.
> >
> > The difference from v1 [1] is removal of the obtain_alias parts, which are
> > wrong for network filesystems.
> >
> > The LTP test provided by Daehyeon now fails because it uses open_by_handle_at()
> > for the reproducer, but a similar race could be created with hardlinks
> > release/unlink race and this case should be fixed by this v2, meaning that
> > FS_DELETE_SELF is reported when all hardlinks are unlinked and all
> > open files to all hardlinks are closed.
> 
> Sorry I forgot to update the comment.
> Attached v3 with the comment change.

Done and in vfs.fixes.
Thanks!
Christian