All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Hungyu Lin <dennylin0707@gmail.com>,
	linux-fsdevel@vger.kernel.org, jack@suse.cz, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v4] inotify13: check rename cookie pairing after adjacent moves
Date: Fri, 30 Oct 2026 18:48:55 +0100	[thread overview]
Message-ID: <20261030174855.GA53338@pevik> (raw)
In-Reply-To: <CAOQ4uxjsf=6Do-uNEOS9R61M8jXcmExY1jnrLNY9ex=doNn3wA@mail.gmail.com>

> On Fri, Oct 30, 2026 at 6:06 PM Petr Vorel <pvorel@suse.cz> wrote:

> > > On Thu, Oct 29, 2026 at 10:07 PM Hungyu Lin <dennylin0707@gmail.com> wrote:

> > > > Queue an unpaired IN_MOVED_FROM event, followed by an IN_MOVED_FROM and
> > > > IN_MOVED_TO pair with the same source watch descriptor and name as the
> > > > first event. Watch only IN_MOVE so creation of the replacement entry
> > > > does not separate the two IN_MOVED_FROM events in the queue.

> > > > Affected kernels coalesce the second IN_MOVED_FROM into the first,
> > > > leaving the IN_MOVED_TO cookie without a matching IN_MOVED_FROM cookie.
> > > > Check that all three events are retained, the two moves have distinct
> > > > cookies, and the second IN_MOVED_FROM matches the IN_MOVED_TO cookie.
> > > > Cover both regular files and directories.

> > > > Suggested-by: Amir Goldstein <amir73il@gmail.com>
> > > > Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>

> > > Thank you for your patience with my review

> > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>

> > Thank you!

> > Reviewed-by: Petr Vorel <pvorel@suse.cz>

> > I have no problem to fix very minor issues reported by agent before merge,
> > but what bothers me there is no kernel fix for the failure.  If I'm not
> > mistaken, the fix in kernel [1] was reviewed [2] but not yet merged (I looked to
> > next tree as well).
> > There are other fixes for 63c882a05416 ("inotify: reimplement inotify using
> > fsnotify") in stable, e.g. e422777fdd474 ("fsnotify: Fix stale object mask after
> > concurrent mark updates"), but I haven't found this one.

> > Merging test helps kernel developers to test if the problem was fixed but break
> > for it for anybody who uses master for regular testing without even explaining
> > fix is WIP. But I suppose it will be processed soon because stable was in Cc,
> > right?

> > We have runtest/staging, but that's for new functionality, not for tests which
> > reproduce problem which was not fixed.

> > @Jan @Amir is there a git kernel tree for fanotify and inotify? I found only
> > VFS. If yes, please update MAINTAINERS file.


> FSNOTIFY: FILESYSTEM NOTIFICATION INFRASTRUCTURE
> M:      Jan Kara <jack@suse.cz>
> R:      Amir Goldstein <amir73il@gmail.com>
> L:      linux-fsdevel@vger.kernel.org
> S:      Maintained
> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> fsnotify
> F:      fs/notify/
> F:      include/linux/fsnotify*.h

Thanks a lot for pointing this doc, I overlooked because I noticed the earlier:

FANOTIFY
M:	Jan Kara <jack@suse.cz>
R:	Amir Goldstein <amir73il@gmail.com>
R:	Matt Bobrowski <matt@bobrowski.net>
L:	linux-fsdevel@vger.kernel.org
S:	Maintained
F:	fs/notify/fanotify/
F:	include/linux/fanotify.h
F:	include/uapi/linux/fanotify.h

INOTIFY
M:	Jan Kara <jack@suse.cz>
R:	Amir Goldstein <amir73il@gmail.com>
L:	linux-fsdevel@vger.kernel.org
S:	Maintained
F:	Documentation/filesystems/inotify.rst
F:	fs/notify/inotify/
F:	include/linux/inotify.h
F:	include/uapi/linux/inotify.h

> We could probably rename/move the fanotify/inotify entries to appear as
> sub entries mimicking the VFS entries:

> FILESYSTEM NOTIFICATION (fsnotify infrastructure)
> ...
> FILESYSTEM NOTIFICATION [INOTIFY]
> ...
> FILESYSTEM NOTIFICATION [FANOTIFY]

+1

Kind regards,
Petr

> Thanks,
> Amir.

WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-fsdevel@vger.kernel.org,
	Hungyu Lin <dennylin0707@gmail.com>,
	jack@suse.cz, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v4] inotify13: check rename cookie pairing after adjacent moves
Date: Fri, 30 Oct 2026 18:48:55 +0100	[thread overview]
Message-ID: <20261030174855.GA53338@pevik> (raw)
In-Reply-To: <CAOQ4uxjsf=6Do-uNEOS9R61M8jXcmExY1jnrLNY9ex=doNn3wA@mail.gmail.com>

> On Fri, Oct 30, 2026 at 6:06 PM Petr Vorel <pvorel@suse.cz> wrote:

> > > On Thu, Oct 29, 2026 at 10:07 PM Hungyu Lin <dennylin0707@gmail.com> wrote:

> > > > Queue an unpaired IN_MOVED_FROM event, followed by an IN_MOVED_FROM and
> > > > IN_MOVED_TO pair with the same source watch descriptor and name as the
> > > > first event. Watch only IN_MOVE so creation of the replacement entry
> > > > does not separate the two IN_MOVED_FROM events in the queue.

> > > > Affected kernels coalesce the second IN_MOVED_FROM into the first,
> > > > leaving the IN_MOVED_TO cookie without a matching IN_MOVED_FROM cookie.
> > > > Check that all three events are retained, the two moves have distinct
> > > > cookies, and the second IN_MOVED_FROM matches the IN_MOVED_TO cookie.
> > > > Cover both regular files and directories.

> > > > Suggested-by: Amir Goldstein <amir73il@gmail.com>
> > > > Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>

> > > Thank you for your patience with my review

> > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>

> > Thank you!

> > Reviewed-by: Petr Vorel <pvorel@suse.cz>

> > I have no problem to fix very minor issues reported by agent before merge,
> > but what bothers me there is no kernel fix for the failure.  If I'm not
> > mistaken, the fix in kernel [1] was reviewed [2] but not yet merged (I looked to
> > next tree as well).
> > There are other fixes for 63c882a05416 ("inotify: reimplement inotify using
> > fsnotify") in stable, e.g. e422777fdd474 ("fsnotify: Fix stale object mask after
> > concurrent mark updates"), but I haven't found this one.

> > Merging test helps kernel developers to test if the problem was fixed but break
> > for it for anybody who uses master for regular testing without even explaining
> > fix is WIP. But I suppose it will be processed soon because stable was in Cc,
> > right?

> > We have runtest/staging, but that's for new functionality, not for tests which
> > reproduce problem which was not fixed.

> > @Jan @Amir is there a git kernel tree for fanotify and inotify? I found only
> > VFS. If yes, please update MAINTAINERS file.


> FSNOTIFY: FILESYSTEM NOTIFICATION INFRASTRUCTURE
> M:      Jan Kara <jack@suse.cz>
> R:      Amir Goldstein <amir73il@gmail.com>
> L:      linux-fsdevel@vger.kernel.org
> S:      Maintained
> T:      git git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git
> fsnotify
> F:      fs/notify/
> F:      include/linux/fsnotify*.h

Thanks a lot for pointing this doc, I overlooked because I noticed the earlier:

FANOTIFY
M:	Jan Kara <jack@suse.cz>
R:	Amir Goldstein <amir73il@gmail.com>
R:	Matt Bobrowski <matt@bobrowski.net>
L:	linux-fsdevel@vger.kernel.org
S:	Maintained
F:	fs/notify/fanotify/
F:	include/linux/fanotify.h
F:	include/uapi/linux/fanotify.h

INOTIFY
M:	Jan Kara <jack@suse.cz>
R:	Amir Goldstein <amir73il@gmail.com>
L:	linux-fsdevel@vger.kernel.org
S:	Maintained
F:	Documentation/filesystems/inotify.rst
F:	fs/notify/inotify/
F:	include/linux/inotify.h
F:	include/uapi/linux/inotify.h

> We could probably rename/move the fanotify/inotify entries to appear as
> sub entries mimicking the VFS entries:

> FILESYSTEM NOTIFICATION (fsnotify infrastructure)
> ...
> FILESYSTEM NOTIFICATION [INOTIFY]
> ...
> FILESYSTEM NOTIFICATION [FANOTIFY]

+1

Kind regards,
Petr

> Thanks,
> Amir.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-10-30 17:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-29 21:07 [LTP] [PATCH v4] inotify13: check rename cookie pairing after adjacent moves Hungyu Lin
2026-10-29 21:07 ` Hungyu Lin
2026-10-30  0:31 ` [LTP] " linuxtestproject.agent
2026-10-30  9:20 ` [LTP] [PATCH v4] " Amir Goldstein
2026-10-30  9:20   ` Amir Goldstein
2026-10-30 17:06   ` [LTP] " Petr Vorel
2026-10-30 17:06     ` Petr Vorel
2026-10-30 17:30     ` Amir Goldstein
2026-10-30 17:30       ` Amir Goldstein
2026-10-30 17:48       ` Petr Vorel [this message]
2026-10-30 17:48         ` Petr Vorel

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=20261030174855.GA53338@pevik \
    --to=pvorel@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=dennylin0707@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    /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.