[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250114164256.GA11820@strace.io>
Date: Tue, 14 Jan 2025 18:42:56 +0200
From: "Dmitry V. Levin" <ldv@...ace.io>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Oleg Nesterov <oleg@...hat.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Eugene Syromyatnikov <evgsyr@...il.com>,
Mike Frysinger <vapier@...too.org>,
Renzo Davoli <renzo@...unibo.it>,
Davide Berardi <berardi.dav@...il.com>,
strace-devel@...ts.strace.io, linux-mips@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/7] mips: fix mips_get_syscall_arg() for O32 and N32
On Tue, Jan 14, 2025 at 04:03:28PM +0000, Maciej W. Rozycki wrote:
> On Tue, 14 Jan 2025, Dmitry V. Levin wrote:
>
> > > How did you produce these results?
> >
> > $ PATH="$HOME/x-tools/mips64-unknown-linux-gnu/bin:$PATH" make -j`nproc` ARCH=mips CROSS_COMPILE=mips64-unknown-linux-gnu- -C tools/testing/selftests TARGETS=ptrace USERLDFLAGS='-static' USERCFLAGS='-mabi=32'
> > $ echo init |(cd tools/testing/selftests/ptrace && ln -snf get_syscall_info init && cpio --dereference -o -H newc -R 0:0) |gzip >get_syscall_info.mips-o32.img
> > $ qemu-system-mips -nographic -kernel vmlinuz -initrd get_syscall_info.mips-o32.img -append 'console=ttyS0'
> >
> > Likewise for mips64, but the patch for kselftest_harness.h from [1]
> > is needed to see correct mismatch values in the test diagnostics.
> >
> > [1] https://lore.kernel.org/all/20250108170757.GA6723@strace.io/
>
> Thanks, I'll try to see what's going on with `get_user'.
Thanks.
> > > The patch is definitely broken, the calling convention is the same
> > > between n32 and n64: 64-bit arguments in $4 through $11 registers as
> > > required, and your change makes n32 truncate arguments to 32 bits.
> >
> > There must be something very specific to n32 then: apparently,
> > __kernel_ulong_t is a 32-bit type on n32, so the syscall arguments are
> > 32-bit values, at some point (in glibc?) they get sign-extended from 32 to
> > 64 bits, and syscall_get_arguments returns them as 64-bit values different
> > from the original syscall arguments, breaking the test.
>
> This matters at least for `lseek', which has an `off64_t' aka `long long'
> argument on n32 (there's no `_llseek' on n32). Since arguments are passed
> via 64-bit registers and a `long long' datum is held in just one this is
> transparent between n32 and n64 (of course on n64 this corresponds to the
> plain `long' data type, so the kernel, which is always n64 for 64-bit
> configurations, sees the incoming argument as `long', and the same stands
> for the outgoing return value).
>
> Surely non-LFS lseek(2) will produce the syscall's `long long' argument
> truncated (cf. sysdeps/unix/sysv/linux/mips/mips64/n32/lseek.c in glibc),
> but both LFS lseek(2) and lseek64(2) will pass the native value on n32.
>
> > If this is the expected behaviour, then I'd have to add an exception for
> > mips n32 both to the kernel test and to strace that uses this interface.
>
> Is MIPS n32 the only psABI across all our architectures supported that
> can have `long long' syscall arguments? I guess it might actually be the
> case, in which case I won't be surprised it needs specific handling.
This is very similar to x32, with the only essential difference:
on x32 the 64-bitness of syscall arguments is exposed to userspace via
__kernel_ulong_t:
arch/x86/include/uapi/asm/posix_types_x32.h:typedef unsigned long long __kernel_ulong_t;
In fact, there is a workaround in strace for this case, and now I realized
that it ceased to work on mips n32 long time ago:
# if defined HAVE___KERNEL_LONG_T && defined HAVE___KERNEL_ULONG_T
# include <asm/posix_types.h>
typedef __kernel_long_t kernel_long_t;
typedef __kernel_ulong_t kernel_ulong_t;
# elif (defined __x86_64__ && defined __ILP32__) || defined LINUX_MIPSN32
typedef long long kernel_long_t;
typedef unsigned long long kernel_ulong_t;
# else
typedef long kernel_long_t;
typedef unsigned long kernel_ulong_t;
# endif
--
ldv
Powered by blists - more mailing lists