On Thu, 3 Jul 2025 at 19:47, Arnd Bergmann <[email protected]> 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
