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

[Petr Vorel]

> On Mon, Oct 24, 2022 at 7:15 PM Petr Vorel <pvorel@suse.cz> wrote:

> > 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).

Hi Amir,

> The kernel UAPI is not very consistent about ENOTSUP vs. EINVAL
> renameat(2), unlink(2), link(2) and other return EINVAL for unsupported flags
> fallocate(2), ioctl(2) and others return ENOTSUP for unsupported commands.
> It's not a clear cut, but ENOTSUP is generally for unsupported fs methods,
> not for unsupported options.

thanks for info, I didn't know that. Otherwise Martin's note to use ENOTSUP
would help.

> > > 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?


> I am fine with writing tests that are friendly to distros that want to backport
> features, that is not what my complaint is about.
> As I wrote to Martin, I will accept any imaginary kernel as an example
> for why the test is wrong for that kernel, but I don't see the bug.

> The desire to distinguish between "this kernel should support
> these init flags but failed" and "this kernel does not support those init flags"
> is not realistic, given that fanotify_init() return codes do not
> distinguish between those two cases.

> The suggested logic to work this out by testing flag by flags is faulty
> because of current and future flag dependencies.

> So show me a real bug, as Martin did, and we will fix it.
thanks for info. Fortunately there is no other bug, besides the one Martin
reported and is trying to fix.

Kind regards,
Petr

> Thanks,
> Amir.