From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] syscalls/fanotify03: skip events from other pids when testing MOUNT|FILESYSTEM
Date: Tue, 5 Mar 2019 03:02:12 -0500 (EST) [thread overview]
Message-ID: <1782236297.5156886.1551772932632.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAOQ4uxgExCCq+Ky4PV5NG8XLgp7CaWjtuAK0uAbYiNpXb4352A@mail.gmail.com>
----- Original Message -----
> On Tue, Mar 5, 2019 at 12:16 AM Jan Stancek <jstancek@redhat.com> wrote:
> >
> > FAN_MARK_MOUNT and FAN_MARK_FILESYSTEM sets up monitoring that can
> > cover entire root "/". So a random background process can interfere
> > with test.
> >
> > For example run test while running following on another terminal
> > to reproduce:
> > while [ True ]; do ls -la /root > /dev/null; done
> >
> > Test fails and hangs until timeout:
> > tst_test.c:1085: INFO: Timeout per run is 0h 05m 00s
> > fanotify03.c:168: INFO: Test #0: inode mark permission events
> > fanotify03.c:236: PASS: got event: mask=10000 pid=7317 fd=7
> > fanotify03.c:236: PASS: got event: mask=20000 pid=7317 fd=7
> > fanotify03.c:136: PASS: child exited correctly
> > fanotify03.c:168: INFO: Test #1: mount mark permission events
> > fanotify03.c:236: PASS: got event: mask=10000 pid=7318 fd=7
> > fanotify03.c:231: FAIL: got event: mask=20000 pid=7306 (expected 7318)
> > fd=7
> > fanotify03.c:223: FAIL: got event: mask=20000 (expected 0) pid=7318 fd=7
> > Test timeouted, sending SIGKILL!
> > tst_test.c:1125: INFO: If you are running on slow machine, try exporting
> > LTP_TIMEOUT_MUL > 1
> > tst_test.c:1126: BROK: Test killed! (timeout?)
> >
> > Skip events that are not from our child when testing FAN_MARK_MOUNT and
> > FAN_MARK_FILESYSTEM. If these are permission events, allow everything.
> >
>
> That's the wrong way to fix the problem.
Can you elaborate? The test still fails if we don't get event
from our child.
>
> Please use .mount_device = 1 to contain the effects of
> FAN_MARK_FILESYSTEM/FAN_MARK_MOUNT to events on the
> test device.
I recall (from long time ago) that we saw some daemons that
could probe new mount points, like gvsfd.
>
> While at it, I see that fanotify05 also sets a FAN_MARK_MOUNT
> without having a private test mount.
> Can fix this by either .mount_device = 1 or using the bind mount
> approach taken by fanotify06.
I see fanotify01 failing as well.
>
> I am assuming you will take care of this.
> If you need me to get involved with the fix let me know.
>
> Thanks,
> Amir.
>
next prev parent reply other threads:[~2019-03-05 8:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-04 22:16 [LTP] [PATCH] syscalls/fanotify03: skip events from other pids when testing MOUNT|FILESYSTEM Jan Stancek
2019-03-05 6:31 ` Amir Goldstein
2019-03-05 8:02 ` Jan Stancek [this message]
2019-03-05 8:48 ` Amir Goldstein
2019-03-05 9:01 ` Jan Stancek
2019-03-05 10:37 ` Amir Goldstein
2019-03-05 10:42 ` Amir Goldstein
2019-03-05 10:46 ` Jan Stancek
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=1782236297.5156886.1551772932632.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--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