From: Petr Vorel <pvorel@suse.cz>
To: Martin Doucha <mdoucha@suse.cz>
Cc: Jan Kara <jack@suse.cz>, LTP List <ltp@lists.linux.it>
Subject: Re: [LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function
Date: Mon, 24 Oct 2022 18:15:49 +0200 [thread overview]
Message-ID: <Y1a6NXkayyy7esM+@pevik> (raw)
In-Reply-To: <d80e2e12-899d-f0d2-27c2-f4a92f1b2be4@suse.cz>
Hi all,
> On 24. 10. 22 16:34, Amir Goldstein wrote:
> > This is how I would fix the problem:
> > <snip>
> > Give or take using more macros and your nicer flag prints.
> > There is no need for auto-detection of the unsupported kernel flags.
> > If the test case is expected to get to fanotify_mark() (i.e. non-zero tc->mask)
> > EINVAL from fanotify_init() always means "unsupported".
> This would be a good approach if fanotify_init() returned distinct error
> code for "flag not implemented", like ENOTSUP. But when EINVAL is returned
> for both "not implemented" and "wrong use", this has a risk of hiding real
> bugs. That's why I'm trying to detect the actual set of flags implemented in
> the running kernel before running the real tests.
Indeed, that's quite surprising (not really, it was added in 2.6.36 and remember
Jan Kara's talk about dnotify/inotify/fanotify history). I wonder if it's
possible to fix (backward compatibility would suffer).
> And since some flags may be backported to older kernels, generating feature
> sets based on kernel version is not a solution.
I guess even some not-important fix was not backported. I guess features aren't
backported to the stable kernel maybe to enterprise kernels (SLES, RHEL), but
even there I'd guess there are related patches backported, not features. But
maybe I'm wrong. Jan and Amir?
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-10-24 16:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 13:08 [LTP] [PATCH v2 0/3] Fix fanotify14 Martin Doucha
2022-10-20 13:08 ` [LTP] [PATCH v2 1/3] fanotify14: Print human-readable test case flags Martin Doucha
2022-11-01 14:29 ` Richard Palethorpe
2022-11-03 11:34 ` Richard Palethorpe
2022-10-20 13:08 ` [LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function Martin Doucha
2022-10-20 15:36 ` Amir Goldstein
2022-10-21 13:49 ` Martin Doucha
2022-10-21 19:03 ` Amir Goldstein
2022-10-24 9:03 ` Martin Doucha
2022-10-24 13:08 ` Amir Goldstein
2022-10-24 13:16 ` Martin Doucha
2022-10-24 14:34 ` Amir Goldstein
2022-10-24 14:58 ` Martin Doucha
2022-10-24 16:15 ` Petr Vorel [this message]
2022-10-24 16:30 ` Amir Goldstein
2022-10-24 17:03 ` Petr Vorel
2022-10-25 8:37 ` Martin Doucha
2022-10-25 9:41 ` Petr Vorel
2022-10-24 16:18 ` Amir Goldstein
2022-10-25 8:51 ` Martin Doucha
2022-10-25 9:48 ` Jan Kara
2022-10-25 13:55 ` Martin Doucha
2022-10-25 16:53 ` Amir Goldstein
2022-10-26 14:34 ` Martin Doucha
2023-05-10 18:38 ` Petr Vorel
2022-10-25 11:11 ` Amir Goldstein
2022-10-20 13:08 ` [LTP] [PATCH v2 3/3] fanotify14: Improve check for unsupported init flags Martin Doucha
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=Y1a6NXkayyy7esM+@pevik \
--to=pvorel@suse.cz \
--cc=jack@suse.cz \
--cc=ltp@lists.linux.it \
--cc=mdoucha@suse.cz \
/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