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

[Daehyeon Ko <4ncienth@gmail.com>]

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@gmail.com>

Thanks,
Daehyeon