All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daehyeon Ko <4ncienth@gmail.com>
To: Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>
Cc: Miklos Szeredi <mszeredi@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] fanotify: destroy/add race leaves a mark on a detached connector
Date: Thu,  3 Sep 2026 06:50:45 +0900	[thread overview]
Message-ID: <20260902215046.1149198-1-4ncienth@gmail.com> (raw)
In-Reply-To: <CAOQ4uxjwGdKhX423KoFxW+T5hc9uzCWSsGwn0-QX=CJipPSaYQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

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.

Thanks,
Daehyeon

[-- Attachment #2: 0001-fanotify-test-duplicate-FAN_DELETE_SELF-after-handle.patch --]
[-- Type: application/x-patch, Size: 11025 bytes --]

  reply	other threads:[~2026-09-02 21:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27  4:50 [BUG] fanotify: destroy/add race leaves a mark on a detached connector Daehyeon Ko
2026-08-27 12:45 ` Amir Goldstein
2026-08-27 16:30 ` Jan Kara
2026-08-28  4:24   ` Daehyeon Ko
2026-08-28  9:05     ` Jan Kara
2026-08-28 10:18       ` Amir Goldstein
2026-08-28 17:36         ` Jan Kara
2026-08-29 15:04           ` Amir Goldstein
2026-08-31 11:39             ` Jan Kara
2026-08-31 14:54               ` Amir Goldstein
2026-09-01 16:57                 ` Jan Kara
2026-09-01 21:53                   ` Amir Goldstein
2026-09-02  7:03                     ` Daehyeon Ko
2026-09-02  7:58                       ` Amir Goldstein
2026-09-02 21:50                         ` Daehyeon Ko [this message]
2026-09-03 13:07                           ` Amir Goldstein
2026-09-02 16:52                     ` Jan Kara
2026-09-02 17:08                       ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260902215046.1149198-1-4ncienth@gmail.com \
    --to=4ncienth@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.