public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 2/4] syscalls/fanotify15: Add a test case for inode marks
Date: Mon, 4 May 2020 20:49:36 +0200	[thread overview]
Message-ID: <20200504184936.GA92715@x230> (raw)
In-Reply-To: <20200504141516.GC1741@quack2.suse.cz>

Hi Jan,

...
> > > > The new test case is a regression test for commit f367a62a7cad:

> > > >     fanotify: merge duplicate events on parent and child

> > > The test looks OK but do we want a test for this? I mean: A test like this
> > > seems to imply we promise to merge identical events. Although that is a
> > > good general guideline, I consider it rather an optimization that may or
> > > may not happen but userspace should not rely on it. Thoughts?

> > The thing is, those are not really two identical events.
> > This is in fact the same event (fsnotify_change() hook was called once).
> > The fact that listener process may have an inode watch, parent directory
> > watch and a filesystem watch should not affect the number of read events.

> Yeah, I agree that in this case we should be merging the event if sanely
> possible (which is why I've merged that patch).

> > Now it's true that internally, fsnotify_dentry() emits two event flavors to
> > parent and to victim. For inotify it even made some sense, because listener
> > would read two different event flavors with two different formats.
> > With fanotify (either reporting fd or fid) receiving two events makes very
> > little sense.

> > I agree that the fix (merging those events) is best effort and we cannot
> > commit to merging the events, but this isolated regression test does
> > check the best effort fix reliably and this is the reason I think it
> > should stay.

> OK, I'm not too concerned about this test. But still the functionality is
> more in the area of "nice to have" than "must have" so in future we may
> break this if the implementation would get too hairy. But I guess we can
> remove the test in that case.
Yes, nothing is set in stone.

> > Upcoming FAN_REPORT_NAME is about to change the picture a bit
> > towards the inotify behavior - victim watch gets event without name,
> > parent watch gets event with name, filesystem watch gets both event
> > flavors... that is, if you will agree to this behavior, but we shall continue
> > this discussion on the fanotiify_name patches....

> Yes.
Can I add your ack tag to the whole patchset?
Or do you still consider whether any of them should be merged?

Kind regards,
Petr

> 								Honza

  reply	other threads:[~2020-05-04 18:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02 16:27 [LTP] [PATCH v2 0/4] fanotify ltp tests for v5.7-rc1 Amir Goldstein
2020-05-02 16:27 ` [LTP] [PATCH v2 1/4] syscalls/fanotify15: Minor corrections Amir Goldstein
2020-05-02 16:27 ` [LTP] [PATCH v2 2/4] syscalls/fanotify15: Add a test case for inode marks Amir Goldstein
2020-05-04  8:07   ` Jan Kara
2020-05-04  8:51     ` Amir Goldstein
2020-05-04 14:15       ` Jan Kara
2020-05-04 18:49         ` Petr Vorel [this message]
2020-05-04 20:27           ` Jan Kara
2020-05-05 12:03             ` Petr Vorel
2020-05-02 16:27 ` [LTP] [PATCH v2 3/4] syscalls/fanotify: New test for FAN_MODIFY_DIR Amir Goldstein
2020-05-04 12:07   ` Petr Vorel
2020-05-04 15:31     ` Amir Goldstein
2020-05-02 16:27 ` [LTP] [PATCH v2 4/4] syscalls/fanotify: Use fanotify_save_fid() helper Amir Goldstein
2020-05-03  8:43   ` Matthew Bobrowski
2020-05-04 12:33   ` Petr Vorel
2020-05-04  5:53 ` [LTP] [PATCH v2 0/4] fanotify ltp tests for v5.7-rc1 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=20200504184936.GA92715@x230 \
    --to=pvorel@suse.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox