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
next prev parent 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