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

[Martin Doucha]

On 24. 10. 22 18:18, Amir Goldstein wrote:
> 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.

Imagine two init flags, A and B (doesn't matter which ones) that are not 
supposed to conflict in any way according to documentation. And we'll 
add 3 fanotify14 test cases with the following init calls:
- fanotify_init(A)
- fanotify_init(B)
- fanotify_init(A|B)

All 3 init calls are supposed to pass and then fanotify_mark() is 
supposed to fail. Now imagine that we have a buggy kernel where both 
flags are implemented but fanotify_init(A|B) hits a weird corner case 
and returns EINVAL. In your version of the code, the test will assume 
that it's due to a missing feature and report the test case as skipped. 
In my version of the code, the test will report a bug because it knows 
that all the required features are present.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic