Bugzilla – Bug 1213486
[Build 44.3] openQA test fails in fanotify14
Last modified: 2024-04-30 12:46:27 UTC
## Observation openQA test in scenario opensuse-15.4-JeOS-for-kvm-and-xen-x86_64-jeos-ltp-syscalls@64bit_virtio fails in [fanotify14](https://openqa.opensuse.org/tests/3439183/modules/fanotify14/steps/7) ## Test suite description ## Reproducible Fails since (at least) Build [44.2](https://openqa.opensuse.org/tests/3438422) ## Expected result Last good: [44.1](https://openqa.opensuse.org/tests/3436580) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=JeOS-for-kvm-and-xen&machine=64bit_virtio&test=jeos-ltp-syscalls&version=15.4)
This is a valid bug also for Tumbleweed and Alp, due this explanation [3]: The fix was merged to v6.5-rc1. I've already posted backport patches for kernels > v5.0 [1]. (69562eb0bd3e ("fanotify: disallow mount/sb marks on kernel internal pseudo fs") [2]) I am not planning to post backport patches for older kernels. which got merged in LTP as [4]. While in Tumbleweed we get fixes sooner or later (not sure how in Alp), in Leap we probably need to backport (it's also in upcoming 5.10.188-rc1 [5] [6]) it or wontfix. [1] https://lore.kernel.org/stable/20230710133205.1154168-1-amir73il@gmail.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69562eb0bd3e6bb8e522a7b254334e0fb30dff0c [3] https://lore.kernel.org/ltp/20230716053530.1629416-1-amir73il@gmail.com/ [4] https://github.com/openSUSE/kernel-qe/commit/83504fcb2f071d3f939a234df89d22b48403b612 [5] https://lore.kernel.org/stable/20230725104607.794023737@linuxfoundation.org/ [6] https://lore.kernel.org/stable/20230725104553.588743331@linuxfoundation.org/
Well, this is not a functionality bug per se. Rather it is a functionality which is not really supported and the patch adds proper error return instead of resulting in rather random behavior. I'd be reluctant to actually backport the commit to released versions of our distro as if accidentally some application depends on the behavior, the update would break it. If the customer finds on distro version update that something is broken, they are in much better setting to fix their application to not depend on broken behavior. So I will push the fix to the 6.4 based kernels we're going to ship with SLE15-SP5 and ALP (in fact stable process is likely to pick it up for them) but for older kernels this is IMO WONTFIX.
In fact commit 69562eb0bd3 is already included in 6.4.4 kernel so that deals with the problem for SLE15-SP5 and ALP. Closing the problem as WONTFIX since it is reported for 15.4.
For some reason I didn't close this bug as I wanted. Doing that now.