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