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

[Amir Goldstein]

On Wed, Sep 2, 2026 at 9:04 AM Daehyeon Ko <4ncienth@xxxxxxxxx> wrote:
>
> Hi Amir,
>
> I tested the exact attached patch (SHA-256
> 9fa187507909ae14c8de8a117e775122e3daa425c69081b7115b3dc979fca14d)
> on Linux v7.2, commit 8d3ae59288f1, with an x86_64 KASAN kernel.
>
> The capless prerequisite probe passed as UID/GID 65534 with CapEff=0 and
> NoNewPrivs=1. I then ran the original reproducer command
>
>   fanotify_destroy_add_race 10000 1 1024 256
>
> in three fresh 2-vCPU boots. All three runs completed 10,000 iterations with
> 10,000 successful adds, zero add errors, and 10,000 fdinfo reads. The complete
> serial logs contain no fsnotify_conn_mask() warning, other kernel warning,
> KASAN report, Oops, panic, or kernel BUG, and both guest and host exited 0.
>
> This tests the originally reported race reproducer. I did not yet test the
> new permission/pre-content, duplicate FAN_DELETE_SELF, open_by_handle_at(), or
> NFS/export-filesystem semantics discussed later in the thread.
>
> Tested-by: Daehyeon Ko <4ncienth@xxxxxxxxx>

Thank you!

If you can think of a way to trigger the race in a reliable LTP regression test
that would be great.

By "reliable" I mean works reliably with some fs at the moment, for example
if ext4 or some other fs practically keeps the inode on disk long
enough for the test
to open_by_handle and get a new dentry for an unlink inode after
FAN_DELETE_SELF,
and then close the fd to get another FAN_DELETE_SELF that's a reliable test.

Jan,

If you end up picking this patch as is please fix the typo
s/fsnotify_removeinode/fsnotify_inoderemove in commit subject/body.
Also, do feel free to rename "dead"/"live" to any other terms that you
find less confusing because yeh the lifetime of inode on-disk/in-core
is a very overloaded namespace.

Thanks,
Amir.