[LTP] [PATCH v3][STAGING] syscalls/fanotify26: Add test for nested permission events

[Petr Vorel]

Hi Edvard, Amir,

> > The kernel creates the file descriptor it reports with a permission
> > event by an open that must not generate further events. When the
> > reported path is on a stacked filesystem, that open opens the real file
> > on the backing filesystem, and since commit ebe559609d78 ("fs: get rid
> > of __FMODE_NONOTIFY kludge") the backing file no longer inherits
> > FMODE_NONOTIFY. A listener that also watches the backing filesystem is
> > then sent a second permission event from inside its own read(2), which
> > only the listener itself can answer, so a single reader never returns.

> > Verify that a listener returns from read(2) and answers an open
> > permission event for a file on an overlayfs mount. The first test case
> > marks the overlay only and passes on any kernel, the second one also
> > marks the backing filesystem, which is the shape an anti-malware
> > scanner uses on an overlayfs root.

> > The second case fails on a kernel without the pending fix "fs: let
> > backing files inherit FMODE_NONOTIFY from the user file", so the test
> > is added to runtest/staging for now.

> > Link: https://lore.kernel.org/all/P58Wrer--F-9@tuta.io/

> > Signed-off-by: Edvard Conrad <edvard@tuta.io>
> > ---
> > v2: https://lore.kernel.org/ltp/P50G-yE--F-9@tuta.io/

> > v3:
> > - Scale both process-state waits through tst_multiply_timeout(). The
> >   library scales all of its own deadlines, so on a KASAN or lockdep
> >   kernel a healthy but unscheduled listener was reported as blocked.
> > - Report TFAIL, not TBROK, for an unexpected event mask, and check the
> >   event's pid, following fanotify03.c. Answer the event either way, or
> >   the opener stays parked in the kernel.

+1.  I first thought wrong mask would be kind of fatal (i.e. to be fixed also in
fanotify03.c), but double checking it looks to be a normal error when test can
continue.

LGTM, I'll merge it in few hours.

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

> > - Probe FAN_CLASS_CONTENT + FAN_MARK_FILESYSTEM + FAN_OPEN_PERM with
> >   REQUIRE_FANOTIFY_EVENTS_SUPPORTED_ON_FS(), the combination run()
> >   actually uses. The two previous probes checked neither class nor mask.
> > - Use SAFE_READ_ALL rather than a literal 1, matching SAFE_WRITE_ALL.
> > - Drop the explicit SAFE_WAITPID() for the opener. tst_reap_children()
> >   runs after every iteration and checks the exit status this discarded.
> > - Drop three unused includes.

> > Amir's Reviewed-by from v2 is not carried over: the failure reporting
> > and the support probe changed since, so it needs a fresh look.

> Still looks good

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


> > Not changed: the [STAGING] keyword stays in the patch subject rather
> > than the commit subject, which is the form ground_rules.rst documents.
> > Answered on the v2 thread.

Sure.

> > Tested on mainline v7.3-16259-g6b4b543fa18 with and without the pending
> > fix: both cases pass with it, and the second fails without it.

FYI Once we get kernel fix in Linus' tree we add it into "linux-git" tag and
move test into runtest/syscalls. Please send then a follow up patch (or Cc me
with info it got merged and I can do it).

Kind regards,
Petr