[LTP] [PATCH v2 2/3] Add fanotify_get_supported_init_flags() helper function

[Amir Goldstein]

On Mon, Oct 24, 2022 at 5:58 PM Martin Doucha <mdoucha@suse.cz> wrote:
>
> 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.

Show me how this could hide a real bug.
Give an example.
It does not need to be a specific kernel
use an example with imaginary kernel with a backported feature if you like.

fanotify14 is not about making sure that flag combinations are allowed
it is about making sure that flag combinations are not allowed.

If the test case is testing illegal init flags, the outcome must be
fanotify_init
EINVAL.

If the test case is testing illegal mark flags, the outcome of fanotify_init
may be EINVAL meaning that this test case will be skipped.
It does not matter which specific init flag or init flag combination
causes this EINVAL.

I am ready to be proven wrong, but with examples,
like the one you provided with test case #8 and kernel 5.3.
hand waving and talking about vague "real bugs" won't convince me.

Thanks,
Amir.