[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260416140031.GE1827@brightrain.aerifal.cx>
Date: Thu, 16 Apr 2026 10:00:31 -0400
From: Rich Felker <dalias@...c.org>
To: Alex Rønne Petersen <alex@...xrp.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] mipsn32: pass syscall arguments as long long
instead of long
On Thu, Apr 16, 2026 at 03:43:38PM +0200, Alex Rønne Petersen wrote:
> On Thu, Apr 16, 2026, at 15:13, Rich Felker wrote:
> > On Thu, Apr 16, 2026 at 04:10:17AM +0200, Alex Rønne Petersen wrote:
> >> This matches what is done for the x32 port. As far as I can tell based on kernel
> >> and glibc sources, this is the expected kABI for mipsn32. Before this patch, you
> >> would get compiler warnings about truncation of off_t values in various syscall
> >> wrappers.
> >
> > This patch doesn't actually do what the description says. The
> > arguments passed in to the __syscallN inlines are long long, but the
> > register locals passed into the inline asm are still long.
>
> Ugh, thanks for pointing that out. I was tunnel-visioning a bit and totally missed that. Will send a v2 if we can agree that the change is correct...
>
> > I'm skeptical that the intendedchange is correct to begin with tho. As
> > I understand it, x32 actually has the kernel receive 64-bit registers
> > and might even use 64-bit values in a few places, but mips n32 always
> > treats the syscall args as 32-bit.
>
> I honestly can't find any evidence that n32 uses 32-bit syscall arguments. I'd be surprised if it did, since a MIPS32_N32 kernel is always 64BIT (in Kconfig terms), and the n32 calling convention uses the full 64-bit registers, so if anything it'd take considerable extra effort for the n32 syscall path to use 32-bit arguments (when you consider e.g. off_t value splitting into separate registers), and I just don't see that anywhere in the kernel code. glibc also explicitly makes __syscall_arg_t 64-bit on n32, just as on x32.
>
> > If off_t is being truncated somewhere, this is probably actually a
> > bug, and the patch is just burying it, not fixing it. Can you report
> > that so it can be investigated?
>
> It's truncated in basically any syscall involving off_t because of
> the definitions of __SYSCALL_LL_E() and __SYSCALL_LL_O() in the
> mipsn32 port. For the x32 port, it's not a problem because syscall
> arguments are passed as 64-bit.
Oh lovely. So we need to figure out if that's how the kernel actually
expects it. If so, your patch is right. But if not, those macro
definitions are wrong.
I believe there was some concern over mipsn32 lseek at some point
return value in the past that was casually raised but never
resolved...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
