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 v3 3/5] fanotify: Introduce SAFE_FANOTIFY_MARK() macro
Date: Wed, 25 Nov 2020 19:24:03 +0100	[thread overview]
Message-ID: <20201125182403.GB7323@pevik> (raw)
In-Reply-To: <20201125141624.GA32471@pevik>

Hi Amir,

> > > > +++ b/testcases/kernel/syscalls/fanotify/fanotify01.c
> > > > @@ -101,19 +101,8 @@ static void test_fanotify(unsigned int n)
> > > >                       "failed", tc->init_flags);
> > > >       }

> > > > -     if (fanotify_mark(fd_notify, FAN_MARK_ADD | mark->flag,
> > > > -                       FAN_ACCESS | FAN_MODIFY | FAN_CLOSE | FAN_OPEN,
> > > > -                       AT_FDCWD, fname) < 0) {
> > > > -             if (errno == EINVAL && mark->flag == FAN_MARK_FILESYSTEM) {
> > > > -                     tst_res(TCONF,
> > > > -                             "FAN_MARK_FILESYSTEM not supported in kernel?");
> > > > -                     return;
> > > > -             }

> > > Here we had tst_res(TCONF, ...) followed by a return but we will can
> > > tst_brk() after the change. I guess that we may skip part of the test on
> > > older kernels with that change.


> > That's not good. I missed that in my review.
> > There are many tests where only the FAN_MARK_FILESYSTEM
> > test cases are expected to result in TCONF, but the rest of the test
> > cases should run.

> I'm not sure if I understand you. Is my approach correct here?
OK, I got that, I cannot use SAFE_FANOTIFY_MARK() in test_fanotify() in fanotify01.c
and in setup_marks() in fanotify13.c.

But FAN_REPORT_FID in is on both files already checked after fanotify_init()
call. Not sure if it must be check also for fanotify_mark(), because it's
only in FANOTIFY_INIT_FLAGS (via FANOTIFY_FID_BITS). FANOTIFY_MARK_FLAGS has
other flags.

If yes, I'll probably need to create fanotify_supported_by_kernel(...), which
check for all not supported flags and will be used in those 2 places and in
safe_fanotify_init(). Something like this:

typedef void (*tst_res_func_t)(const char *file, const int lineno,
		int ttype, const char *fmt, ...);

int fanotify_flags_supported_by_kernel(const char *file, const int lineno,
	unsigned int flags, int strict)
{
	tst_res_func_t res_func = tst_res_;
	int unsupported = 0;

	if (strict)
		res_func = tst_brk_;

	if (errno == EINVAL) {
		if (flags & FAN_REPORT_TID) {
			tst_res_(file, lineno, TINFO,
					 "FAN_REPORT_TID not supported by kernel?");
			unsupported = 1;
		}

		if (flags & FAN_REPORT_FID) {
			tst_res_(file, lineno, TINFO,
					 "FAN_REPORT_FID not supported by kernel?");
			unsupported = 1;
		}

		if (flags & FAN_REPORT_DIR_FID) {
			tst_res_(file, lineno, TINFO,
					 "FAN_REPORT_DIR_FID not supported by kernel?");
			unsupported = 1;
		}

		if (flags & FAN_REPORT_NAME) {
			tst_res_(file, lineno, TINFO,
					 "FAN_REPORT_NAME not supported by kernel?");
			unsupported = 1;
		}

		if (unsupported)
			res_func(file, lineno, TCONF, "Unsupported configuration, see above");
		else
			tst_brk_(file, lineno, TBROK, "Unknown failure");

		return -1;
	}

	return 0;
}

These are flags for fanotify_init(). Flags for fanotify_mark() are currently
handled by fanotify_exec_events_supported_by_kernel() (used for FAN_OPEN_EXEC
and FAN_OPEN_EXEC_PERM), using different approach. Testing fanotify_mark() flags
support in advance in setup makes tests faster, I'm just not happy we use
different approach. Any tip for improving this or improving readability is
welcome.

Kind regards,
Petr

> > In most of these tests the FAN_MARK_FILESYSTEM test cases are
> > last because they were added later. This is not the case with fanotify01
> > and fanotify15 and we do not want to reply on the ordering anyway.

> > Thanks,
> > Amir.

  parent reply	other threads:[~2020-11-25 18:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-13 16:49 [LTP] [PATCH v3 0/5] Introduce SAFE_FANOTIFY_MARK() macro + cleanup Petr Vorel
2020-11-13 16:49 ` [LTP] [PATCH v3 1/5] fanotify12: Drop incorrect hint Petr Vorel
2020-11-19 10:06   ` Cyril Hrubis
2020-11-13 16:49 ` [LTP] [PATCH v3 2/5] fanotify: Handle supported features checks in setup() Petr Vorel
2020-11-19 10:16   ` Cyril Hrubis
2020-11-25 16:56     ` Petr Vorel
2020-11-13 16:49 ` [LTP] [PATCH v3 3/5] fanotify: Introduce SAFE_FANOTIFY_MARK() macro Petr Vorel
2020-11-19 10:27   ` Cyril Hrubis
2020-11-19 10:54     ` Amir Goldstein
2020-11-25 14:16       ` Petr Vorel
2020-11-25 15:41         ` Amir Goldstein
2020-11-25 18:24         ` Petr Vorel [this message]
2020-11-25 19:55           ` Amir Goldstein
2020-11-25 20:25             ` Petr Vorel
2020-11-26  3:00               ` Amir Goldstein
2020-11-13 16:49 ` [LTP] [PATCH v3 4/5] fanotify: Check FAN_REPORT_{FID, NAME} support Petr Vorel
2020-11-19 10:30   ` Cyril Hrubis
2020-11-13 16:49 ` [LTP] [PATCH v3 5/5] fanotify: Add a pedantic check for return value Petr Vorel
2020-11-19 10:31   ` Cyril Hrubis

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=20201125182403.GB7323@pevik \
    --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