Message-Id: <1268665412.19726.75.camel@spokane1.rchland.ibm.com>
Date:	Mon, 15 Mar 2010 10:03:32 -0500
From:	Steven Munroe <munroesj@...ux.vnet.ibm.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	"Ryan S. Arnold" <rsa@...ibm.com>
Cc:	linux-arch@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Lord <kernel@...savvy.com>,
	Ulrich Drepper <drepper@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 64-syscall args on 32-bit vs syscall()

On Mon, 2010-03-15 at 15:48 +1100, Benjamin Herrenschmidt wrote:
> Hoy there !
> 
> This may have been discussed earlier (I have some vague memories...) but
> I just hit a problem with that again (Mark: hint, it's in hdparm's
> fallocate) so I'd like a bit of a refresh here on what is the "right
> thing" to do...
> 
> So some syscalls want a 64-bit argument. Let's take fallocate() as our
> example. So we already know that we have to be extra careful since some
> 32-bit arch will pass this into 2 registers (or stack slots) which need
> to be aligned, and so we tend to already take care of making sure that
> the said 64-bit argument is either defined as 2x32-bit arguments, or
> defined as 1x64 bit argument aligned to 2x32-bit in the argument list.
> 
> So far so good...
> 
> The problem is when user space tries to use the same trick for calling
> those functions using glibc-provided syscall() function. In this
> example, hdparm does:
> 
> err = syscall(SYS_fallocate, fd, mode, offset, len);
> 
> With "offset" being a 64-bit argument.
> 

The powerpc implementation of syscall is:


ENTRY (syscall)
	mr   r0,r3
	mr   r3,r4
	mr   r4,r5
	mr   r5,r6
	mr   r6,r7
	mr   r7,r8
	mr   r8,r9
	sc
	PSEUDO_RET
PSEUDO_END (syscall)

The ABI says:

"Long long arguments are considered to have 8-byte size and alignment.
The same 8-byte arguments that must go in aligned pairs or registers are
8-byte aligned on the stack."

This implies that the SYS_fallocate call will skip a register to get the
required alignment in the parameter save area.

for ppc32 on entry

r3 == SYS_fallocate
r4 == fd
r5 == mode
r6 == not used
r7, r8 == offset
r9 == len

This gets shifted to:

r0 == SYS_fallocate
r3 == fd
r4 == mode
r5 == not used
r6, r7 == offset
r8 == len

For syscall the vararg parms will be mirrored to the parameter save area
but will not be used. The ABI does not talk to LE for this case.

Ryan does the new ABI doc cover this?

> This will break because the first argument to syscall now shifts
> everything by one register, which breaks the register pair alignment
> (and I suppose archs with stack based calling convention can have
> similar alignment issues even if x86 doesn't).
> 
> Ulrich, Steven, shouldn't we have glibc's syscall() take a long long as
> it's first argument to correct that ? Either that or making it some kind
> of macro wrapper around a __syscall(int dummy, int sysno, ...) ?
> 
> As it is, any 32-bit app using syscall() on any of the syscalls that
> takes 64-bit arguments will be broken, unless the app itself breaks up
> the argument, but the the order of the hi and lo part is different
> between BE and LE architectures ;-)
> 
> So is there a more "correct" solution than another here ? Should powerpc
> glibc be fixed at least so that syscall() keeps the alignment ?
> 
> Cheers,
> Ben.
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists