From: "Dmitry V. Levin" <ldv@strace.io>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Oleg Nesterov <oleg@redhat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Eugene Syromyatnikov <evgsyr@gmail.com>,
Mike Frysinger <vapier@gentoo.org>,
Renzo Davoli <renzo@cs.unibo.it>,
Davide Berardi <berardi.dav@gmail.com>,
strace-devel@lists.strace.io, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/7] mips: fix mips_get_syscall_arg() for O32 and N32
Date: Tue, 14 Jan 2025 10:47:09 +0200 [thread overview]
Message-ID: <20250114084709.GA3580@strace.io> (raw)
In-Reply-To: <alpine.DEB.2.21.2501140213050.50458@angie.orcam.me.uk>
On Tue, Jan 14, 2025 at 03:29:11AM +0000, Maciej W. Rozycki wrote:
> On Mon, 13 Jan 2025, Dmitry V. Levin wrote:
>
> > Fix the following get_syscall_info test assertion on mips O32:
> > # get_syscall_info.c:218:get_syscall_info:Expected exp_args[5] (3134521044) == info.entry.args[4] (4911432)
> > # get_syscall_info.c:219:get_syscall_info:wait #1: entry stop mismatch
> >
> > Fix the following get_syscall_info test assertion on mips64 O32 and mips64 N32:
> > # get_syscall_info.c:209:get_syscall_info:Expected exp_args[2] (3134324433) == info.entry.args[1] (18446744072548908753)
> > # get_syscall_info.c:210:get_syscall_info:wait #1: entry stop mismatch
>
> 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/
> > This makes ptrace/get_syscall_info selftest pass on mips O32,
> > mips64 O32, and mips64 N32.
> >
> > Signed-off-by: Dmitry V. Levin <ldv@strace.io>
> > ---
> >
> > Note that I'm not a MIPS expert, so I cannot tell why the get_user()
> > approach doesn't work for O32. Also, during experiments I discovered that
> > regs->pad0 approach works for O32, but why it works remains a mystery.
>
> 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.
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.
> The regs->pad0 approach works due to this piece:
>
> /*
> * Ok, copy the args from the luser stack to the kernel stack.
> */
>
> .set push
> .set noreorder
> .set nomacro
>
> load_a4: user_lw(t5, 16(t0)) # argument #5 from usp
> load_a5: user_lw(t6, 20(t0)) # argument #6 from usp
> load_a6: user_lw(t7, 24(t0)) # argument #7 from usp
> load_a7: user_lw(t8, 28(t0)) # argument #8 from usp
> loads_done:
>
> sw t5, 16(sp) # argument #5 to ksp
> sw t6, 20(sp) # argument #6 to ksp
> sw t7, 24(sp) # argument #7 to ksp
> sw t8, 28(sp) # argument #8 to ksp
> .set pop
>
> .section __ex_table,"a"
> PTR_WD load_a4, bad_stack_a4
> PTR_WD load_a5, bad_stack_a5
> PTR_WD load_a6, bad_stack_a6
> PTR_WD load_a7, bad_stack_a7
> .previous
>
> in arch/mips/kernel/scall32-o32.S (and arch/mips/kernel/scall64-o32.S has
> analogous code to adapt to the native n64 calling convention instead), but
> this doesn't seem to me to be the correct approach here. At first glance
> `mips_get_syscall_arg' does appear fine as it is, so I'd like to know how
> you obtained your results.
>
> Maciej
--
ldv
next prev parent reply other threads:[~2025-01-14 8:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250113170925.GA392@strace.io>
2025-01-13 17:11 ` [PATCH v2 2/7] mips: fix mips_get_syscall_arg() for O32 and N32 Dmitry V. Levin
2025-01-14 3:29 ` Maciej W. Rozycki
2025-01-14 8:47 ` Dmitry V. Levin [this message]
2025-01-14 16:03 ` Maciej W. Rozycki
2025-01-14 16:42 ` Dmitry V. Levin
2025-01-13 17:11 ` [PATCH v2 3/7] syscall.h: add syscall_set_arguments() and syscall_set_return_value() Dmitry V. Levin
2025-01-16 2:20 ` Charlie Jenkins
2025-01-17 0:59 ` H. Peter Anvin
2025-01-17 15:45 ` Eugene Syromyatnikov
2025-01-18 4:34 ` H. Peter Anvin
2025-01-13 17:11 ` [PATCH v2 4/7] syscall.h: introduce syscall_set_nr() Dmitry V. Levin
2025-01-16 2:20 ` Charlie Jenkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250114084709.GA3580@strace.io \
--to=ldv@strace.io \
--cc=berardi.dav@gmail.com \
--cc=evgsyr@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=oleg@redhat.com \
--cc=renzo@cs.unibo.it \
--cc=strace-devel@lists.strace.io \
--cc=tsbogend@alpha.franken.de \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).