Re: [PATCH v2 2/7] mips: fix mips_get_syscall_arg() for O32 and N32

["Dmitry V. Levin" <ldv@strace.io>]

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