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

[Naresh Kamboju]

On Thu, 3 Jul 2025 at 19:47, Arnd Bergmann <arnd@arndb.de> wrote:
>
> 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?

No.
Running on the real x86_64 machine.

- Naresh

>
>      Arnd