The LTP syscalls mseal02 and shmctl03 failed only with compat mode testing with 64-bit kernel with 32-bit rootfs combination.
Would it be possible to detect compat mode test environment and handle the test expectation in LTP test development ?
Test case: - ltp-syscalls/mseal02 - ltp-syscalls/shmctl03
Test environments: - qemu-arm64-compat - qemu-x86_64-compat - x86-compat
Regression Analysis: - New regression? Yes - Reproducibility? Yes
Test regression: LTP mseal02.c:45: TFAIL: mseal(0xf7a8e000, 4294963201, 0) expected EINVAL: ENOMEM (12)
Test regression: LTP shmctl03.c:33: TFAIL: /proc/sys/kernel/shmmax != 2147483647 got 4294967295
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Test log tst_test.c:1953: TINFO: LTP version: 20250530 tst_test.c:1956: TINFO: Tested kernel: 6.16.0-rc4-next-20250701 #1 SMP PREEMPT @1751364932 aarch64 tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz' tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected which might slow the execution tst_test.c:1774: TINFO: Overall timeout per run is 0h 21m 36s mseal02.c:45: TPASS: mseal(0xf7a8e000, 4096, 4294967295) : EINVAL (22) mseal02.c:45: TPASS: mseal(0xf7a8e001, 4096, 0) : EINVAL (22) mseal02.c:45: TFAIL: mseal(0xf7a8e000, 4294963201, 0) expected EINVAL: ENOMEM (12) mseal02.c:45: TPASS: mseal(0xf7a90000, 8192, 0) : ENOMEM (12) mseal02.c:45: TPASS: mseal(0xf7a8f000, 8192, 0) : ENOMEM (12) mseal02.c:45: TPASS: mseal(0xf7a8e000, 16384, 0) : ENOMEM (12)
tst_test.c:1953: TINFO: LTP version: 20250530 tst_test.c:1956: TINFO: Tested kernel: 6.16.0-rc3-next-20250627 #1 SMP PREEMPT @1751015729 aarch64 tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz' tst_kconfig.c:676: TINFO: CONFIG_TRACE_IRQFLAGS kernel option detected which might slow the execution tst_test.c:1774: TINFO: Overall timeout per run is 0h 21m 36s shmctl03.c:31: TPASS: shmmin = 1 shmctl03.c:33: TFAIL: /proc/sys/kernel/shmmax != 2147483647 got 4294967295 shmctl03.c:34: TPASS: /proc/sys/kernel/shmmni = 4096 shmctl03.c:35: TFAIL: /proc/sys/kernel/shmall != 4278190079 got 4294967295
## Source * Kernel version: 6.16.0-rc4-next-20250701 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git sha: 3f804361f3b9af33e00b90ec9cb5afcc96831e60 * Git describe: 6.16.0-rc4-next-20250701 * Project details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250701/ * Architectures: arm64 * Toolchains: gcc-13 * Build name: gcc-13-lkftconfig-compat
## Build arm64 * Test log: https://qa-reports.linaro.org/api/testruns/28971382/log_file/ * Test details 1: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250701/tes... * Test details 2: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250627/tes... * Test results compare 1: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250701/tes... * Test results compare 2: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250627/tes... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2zGk12rggXwQHzqasQsWp... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2zGk12rggXwQHzqasQsWp...
-- Linaro LKFT https://lkft.linaro.org
On Thu, Jul 3, 2025, at 15:47, Naresh Kamboju wrote:
The LTP syscalls mseal02 and shmctl03 failed only with compat mode testing with 64-bit kernel with 32-bit rootfs combination.
Would it be possible to detect compat mode test environment and handle the test expectation in LTP test development ?
I think we should either make the kernel behave the same way in both environments, or accept either behavior as correct in LTP. NVAL (22)
mseal02.c:45: TPASS: mseal(0xf7a8e001, 4096, 0) : EINVAL (22) mseal02.c:45: TFAIL: mseal(0xf7a8e000, 4294963201, 0) expected EINVAL: ENOMEM (12)
This is "length=ULONG_MAX-page_size+2", which overflows on 32-bit but not on 64-bit.
How about this?
--- a/mm/mseal.c +++ b/mm/mseal.c @@ -234,6 +234,9 @@ int do_mseal(unsigned long start, size_t len_in, unsigned long flags) if (end < start) return -EINVAL;
+ if (end > TASK_SIZE) + return -EINVAL; + if (end == start) return 0;
Since TASK_SIZE is smaller for 32-bit tasks, it would detect the overflow in the same way.
tst_test.c:1774: TINFO: Overall timeout per run is 0h 21m 36s shmctl03.c:31: TPASS: shmmin = 1 shmctl03.c:33: TFAIL: /proc/sys/kernel/shmmax != 2147483647 got 4294967295
I see this is being intentionally truncated to INT_MAX:
static int copy_compat_shminfo_to_user(void __user *buf, struct shminfo64 *in, int version) { if (in->shmmax > INT_MAX) in->shmmax = INT_MAX; ... }
shmctl03.c:35: TFAIL: /proc/sys/kernel/shmall != 4278190079 got 4294967295
Here the value from /proc is defined in the kernel as "#define SHMALL (ULONG_MAX - (1UL << 24))"
On a 64-bit machine this is 0xfffffffffeffffff.
However the 32-bit ltp tst_assert_ulong() truncates it to 0xfeffffff, which happens to be the exact same value that it would see on a 32-bit kernel.
The second one is 0xffffffff, and I don't know how that gets computed, as it is derived from the same number in info.shmall = in->shmall;
Are you running this inside of a container that its own ipc namespace?
Arnd
linux-kselftest-mirror@lists.linaro.org
-
Arnd Bergmann -
Naresh Kamboju