[LTP] LTP syscalls mseal02 and shmctl03 fails on compat mode 64-bit kernel on 32-bit rootfs

[Arnd Bergmann]

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