[LTP] [PATCH] listmount04: Allow both EINVAL and EBADF for BEFORE_6_17_9 case

[Andrea Cervesato]

Hi Wake,

> On some LTS kernels (like 6.12.y or 6.6.y), the bug fix
> commit 78f0e33cd6c9 ("fs/namespace: correctly handle errors returned
> by grab_requested_mnt_ns") was backported.

Actually that commit is included from 6.18, which make it non-available
also in 6.17.9. The `BEFORE_6_17_9` variable excludes 6.17.9 (equivalent
to < operation).

This means the patch is not resolving the issue for that specific kernel,
but only for the kernels before that commit. Is that correct?

For instance, the patch fails with `v6.18-rc1-118-ga3f8f8662771`:

tst_test.c:2042: TINFO: Tested kernel: 6.18.0-rc1-virtme #9 SMP PREEMPT_DYNAMIC Mon May  4 13:01:41 CEST 2026 x86_64
tst_kconfig.c:90: TINFO: Parsing kernel config '/lib/modules/6.18.0-rc1-virtme/build/.config'
tst_test.c:1867: TINFO: Overall timeout per run is 0h 00m 30s
listmount04.c:161: TPASS: request points to unaccessible memory : EFAULT (14)
listmount04.c:161: TPASS: mnt_ids points to unaccessible memory : EFAULT (14)
listmount04.c:161: TPASS: invalid flags : EINVAL (22)
listmount04.c:161: TPASS: insufficient mnt_id_req.size : EINVAL (22)
listmount04.c:141: TCONF: Test not suitable for current kernel version
listmount04.c:161: TFAIL: invalid mnt_id_req.mnt_ns_fd expected EBADF: EINVAL (22)
listmount04.c:161: TPASS: invalid mnt_id_req.param : EINVAL (22)
listmount04.c:161: TPASS: invalid mnt_id_req.mnt_id : EINVAL (22)
listmount04.c:161: TPASS: non-existant mnt_id : ENOENT (2)

Summary:
passed   7
failed   1
broken   0
skipped  1
warnings 0

I guess the choice is to use EINVAL when >= 6.18. EBADF otherwise.

Kind regards,
--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com