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