RE: Regarding select() on PPC

-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Tuesday, September 23, 2008 12:00 PM
To: Arnd Bergmann
Cc: <redacted>; Sadashiiv, Halesh
Subject: Re: Regarding select() on PPC

On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:

quoted

No, sorry, I don't have a git history that I can search for that.
I have a strong guess that it would be the end of the last century
though, probably before 2.3.48, since the comment in there already
refers to legacy binaries.

Yeah, I'm keen to rip it out.

Means argument checking in ppc_select() can be removed??
Than shall I post patch to linuxppc-dev@ozlabs.org

Ben.

-------------------------------------------------------------------
This email is confidential and intended only for the use of the =
individual or entity named above and may contain information that is =
privileged. If you are not the intended recipient, you are notified that =
any dissemination, distribution or copying of this email is strictly =
prohibited. If you have received this email in error, please notify us =
immediately by return email or telephone and destroy the original =
message. - This mail is sent via Sony Asia Pacific Mail Gateway.
-------------------------------------------------------------------

On Tue, 2008-09-23 at 12:46 +0530, Sadashiiv, Halesh wrote:

quoted

-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Tuesday, September 23, 2008 12:00 PM
To: Arnd Bergmann
Cc: <redacted>; Sadashiiv, Halesh
Subject: Re: Regarding select() on PPC

On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:

quoted

No, sorry, I don't have a git history that I can search for that.
I have a strong guess that it would be the end of the last century
though, probably before 2.3.48, since the comment in there already
refers to legacy binaries.

Yeah, I'm keen to rip it out.

Means argument checking in ppc_select() can be removed??
Than shall I post patch to linuxppc-dev@ozlabs.org

ppc_select can probably be removed alltogether and ppc32_select too

Ben.

On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:

quoted

Means argument checking in ppc_select() can be removed??
Than shall I post patch to linuxppc-dev@ozlabs.org

ppc_select can probably be removed alltogether and ppc32_select too

I think ppc32_select needs to stay. It never did the hack for
supporting the old_select calling conventions, but it does the
sign extension for the 32 bit arguments, which I think you still
want.

In any way, both the 32 bit emulation and the native ppc32 code
path should do the same thing, which currently they don't.

	Arnd <><

On Wed, 2008-09-24 at 08:23 +0200, Arnd Bergmann wrote:

On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:

quoted

quoted

Means argument checking in ppc_select() can be removed??
Than shall I post patch to linuxppc-dev@ozlabs.org

ppc_select can probably be removed alltogether and ppc32_select too

I think ppc32_select needs to stay. It never did the hack for
supporting the old_select calling conventions, but it does the
sign extension for the 32 bit arguments, which I think you still
want.

Why do we want it ?

It's an int, it's zero extended, but that should still be a valid signed
32 bits int in compat_sys_select() or do I miss something ?
 
Ben.

In any way, both the 32 bit emulation and the native ppc32 code
path should do the same thing, which currently they don't.

	Arnd <><

The ppc_select function was introduced in linux-2.3.48 in order to support
code confusing the legacy select() calling convention with the standard one.
Even 11 years ago, all correctly built code should not have done this and
could have easily been phased out. Nothing that was compiled later should
actually try to use the old_select interface, and it would have been broken
already on all ppc64 kernels with the syscall emulation layer.

This patch brings the 32 bit compat ABI and the native 32 bit ABI for
powerpc into a consistent state, by removing support for both the
old_select system call number and the handler for it.

The bug report triggering this came from Halesh Sadashiiv [off-list ref], who discovered that the 32 bit
implementation of ppc_select would in case of a negative number
of file descriptors incorrectly return -EFAULT instead of -EINVAL.
There seems to be no way to fix this problem in a way that would
keep broken pre-1997 binaries running.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Halesh Sadashiiv <redacted>
---

Halesh, please test this patch to make sure it fixes the problem
you reported. I do not have a ppc32 machine I can try this on.

diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h
index e07d0c7..46107cc 100644
--- a/arch/powerpc/include/asm/unistd.h
+++ b/arch/powerpc/include/asm/unistd.h

@@ -92,7 +92,7 @@
 #define __NR_settimeofday       79
 #define __NR_getgroups          80
 #define __NR_setgroups          81
-#define __NR_select             82
+/* Number 82 was the old (pre-1.3.x) select */
 #define __NR_symlink            83
 #define __NR_oldlstat           84
 #define __NR_readlink           85

diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h
index f6cc7a4..5a69b32 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h

@@ -85,7 +85,7 @@ COMPAT_SYS_SPU(gettimeofday)
 COMPAT_SYS_SPU(settimeofday)
 COMPAT_SYS_SPU(getgroups)
 COMPAT_SYS_SPU(setgroups)
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(sys_ni_syscall)
 SYSCALL_SPU(symlink)
 OLDSYS(lstat)
 COMPAT_SYS_SPU(readlink)

@@ -145,7 +145,7 @@ SYSCALL_SPU(setfsuid)
 SYSCALL_SPU(setfsgid)
 SYSCALL_SPU(llseek)
 COMPAT_SYS_SPU(getdents)
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
 SYSCALL_SPU(flock)
 SYSCALL_SPU(msync)
 COMPAT_SYS_SPU(readv)

diff --git a/arch/powerpc/kernel/syscalls.c b/arch/powerpc/kernel/syscalls.c
index c04832c..c2e6a74 100644
--- a/arch/powerpc/kernel/syscalls.c
+++ b/arch/powerpc/kernel/syscalls.c

@@ -183,31 +183,6 @@ unsigned long sys_mmap(unsigned long addr, size_t len,
 	return do_mmap2(addr, len, prot, flags, fd, offset, PAGE_SHIFT);
 }
 
-#ifdef CONFIG_PPC32
-/*
- * Due to some executables calling the wrong select we sometimes
- * get wrong args.  This determines how the args are being passed
- * (a single ptr to them all args passed) then calls
- * sys_select() with the appropriate args. -- Cort
- */
-int
-ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set __user *exp, struct timeval __user *tvp)
-{
-	if ( (unsigned long)n >= 4096 )
-	{
-		unsigned long __user *buffer = (unsigned long __user *)n;
-		if (!access_ok(VERIFY_READ, buffer, 5*sizeof(unsigned long))
-		    || __get_user(n, buffer)
-		    || __get_user(inp, ((fd_set __user * __user *)(buffer+1)))
-		    || __get_user(outp, ((fd_set  __user * __user *)(buffer+2)))
-		    || __get_user(exp, ((fd_set  __user * __user *)(buffer+3)))
-		    || __get_user(tvp, ((struct timeval  __user * __user *)(buffer+4))))
-			return -EFAULT;
-	}
-	return sys_select(n, inp, outp, exp, tvp);
-}
-#endif
-
 #ifdef CONFIG_PPC64
 long ppc64_personality(unsigned long personality)
 {

On Wednesday 24 September 2008, Benjamin Herrenschmidt wrote:

Why do we want it ?

It's an int, it's zero extended, but that should still be a valid signed
32 bits int in compat_sys_select() or do I miss something ?

IIRC, the calling conventions on 64 bit ppc assume that a signed int
argument is sign-extended into a 64 bit register. The compat syscall
entry point does not know which registers are signed or unsigned, so
it will always to zero-extend, making the register contain an undefined
bit pattern (e.g. 0x00000000fffffffe), which may be interpreted as being
a positive number. An explicit cast as it is done in ppc32_select turns
this into a well-defined 32-bit number stored in a 64-bit register (e.g.
0xfffffffffffffffe).

	Arnd <><

On Wed, 2008-09-24 at 08:45 +0200, Arnd Bergmann wrote:

On Wednesday 24 September 2008, Benjamin Herrenschmidt wrote:

quoted

Why do we want it ?

It's an int, it's zero extended, but that should still be a valid signed
32 bits int in compat_sys_select() or do I miss something ?

IIRC, the calling conventions on 64 bit ppc assume that a signed int
argument is sign-extended into a 64 bit register. The compat syscall
entry point does not know which registers are signed or unsigned, so
it will always to zero-extend, making the register contain an undefined
bit pattern (e.g. 0x00000000fffffffe), which may be interpreted as being
a positive number. An explicit cast as it is done in ppc32_select turns
this into a well-defined 32-bit number stored in a 64-bit register (e.g.
0xfffffffffffffffe).

If that is true, then _any_ syscall that takes an int value must have
a ppc specific sign-extending compat wrapper, are you sure that is
the case ?

Ben.

Arnd Bergmann writes:

I don't see any reason to remove the old select syscall on 32-bit
kernels.  I think this hunk below is the only part of the patch that
we actually need:

Paul.

On Wednesday 24 September 2008, Paul Mackerras wrote:

quoted

diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/a=

sm/systbl.h

quoted

index f6cc7a4..5a69b32 100644

--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h

@@ -85,7 +85,7 @@ COMPAT_SYS_SPU(gettimeofday)

=A0COMPAT_SYS_SPU(settimeofday)
=A0COMPAT_SYS_SPU(getgroups)
=A0COMPAT_SYS_SPU(setgroups)
-SYSX(sys_ni_syscall,sys_ni_syscall,ppc_select)
+SYSCALL(sys_ni_syscall)

=20
I don't see any reason to remove the old select syscall on 32-bit
kernels. =A0

Well, the point I made earlier ist that the native ppc32 path should
behave the same way as the compat ppc32 path. If we keep ppc_select
in one way or another, we should also have a compat wrapper for that,
right?

	Arnd <><

If that is true, then _any_ syscall that takes an int value must have
a ppc specific sign-extending compat wrapper, are you sure that is
the case ?

Ok, so that's crap that has been bitrotting. We -do- need to sign extend
everywhere and it looks like we forgot to do it on anything recent, like
signalfd4...

Ben.

On Wed, 2008-09-24 at 08:39 +0200, Arnd Bergmann wrote:

The ppc_select function was introduced in linux-2.3.48 in order to support
code confusing the legacy select() calling convention with the standard one.
Even 11 years ago, all correctly built code should not have done this and
could have easily been phased out. Nothing that was compiled later should
actually try to use the old_select interface, and it would have been broken
already on all ppc64 kernels with the syscall emulation layer.

This patch brings the 32 bit compat ABI and the native 32 bit ABI for
powerpc into a consistent state, by removing support for both the
old_select system call number and the handler for it.

 .../...

It's me or the patch is whitespaces damaged ?

Cheers,
Ben.

Arnd Bergmann writes:

Well, the point I made earlier ist that the native ppc32 path should
behave the same way as the compat ppc32 path. If we keep ppc_select
in one way or another, we should also have a compat wrapper for that,
right?

No - we have other old system calls that don't exist at all on a
64-bit kernel but do on a 32-bit kernel.  We decided a long time ago
that there was no point supporting really ancient 32-bit userland code
on a 64-bit kernel.  That doesn't mean we need to rip out the support
from the 32-bit kernel.

Paul.

Benjamin Herrenschmidt writes:

On Wed, 2008-09-24 at 08:39 +0200, Arnd Bergmann wrote:

quoted

The ppc_select function was introduced in linux-2.3.48 in order to support
code confusing the legacy select() calling convention with the standard one.
Even 11 years ago, all correctly built code should not have done this and
could have easily been phased out. Nothing that was compiled later should
actually try to use the old_select interface, and it would have been broken
already on all ppc64 kernels with the syscall emulation layer.

This patch brings the 32 bit compat ABI and the native 32 bit ABI for
powerpc into a consistent state, by removing support for both the
old_select system call number and the handler for it.

 .../...

It's me or the patch is whitespaces damaged ?

Please don't apply Arnd's patch.  As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:

-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)

Paul.

On Friday 10 October 2008, Paul Mackerras wrote:

Arnd Bergmann writes:
=20

quoted

Well, the point I made earlier ist that the native ppc32 path should
behave the same way as the compat ppc32 path. If we keep ppc_select
in one way or another, we should also have a compat wrapper for that,
right?

=20
No - we have other old system calls that don't exist at all on a
64-bit kernel but do on a 32-bit kernel. =A0We decided a long time ago
that there was no point supporting really ancient 32-bit userland code
on a 64-bit kernel. =A0That doesn't mean we need to rip out the support
from the 32-bit kernel.

Ok, that makes sense, thanks for the clarification.

	Arnd <><

On Friday 10 October 2008, Paul Mackerras wrote:

Please don't apply Arnd's patch. =A0As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:
=20
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
=20
Paul.

=46WIW,

Acked-by: Arnd Bergmann <arnd@arndb.de>

On Fri, 2008-10-10 at 18:43 +1100, Paul Mackerras wrote:

quoted

It's me or the patch is whitespaces damaged ?

Please don't apply Arnd's patch.  As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:

-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)

Ok, so you want to keep compat with the old stuff. Note that we still
have this weird thing that on 64-bit kernels, we don't provide this.

Ben.

On Saturday 11 October 2008, Benjamin Herrenschmidt wrote:

quoted

-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)

Ok, so you want to keep compat with the old stuff. Note that we still
have this weird thing that on 64-bit kernels, we don't provide this.

This change makes the funny wrapper only active for the "old" select
number on native ppc32, which is not active on ppc64 or compat32,
while any programs using the "new" select number, i.e. any binay you
will ever encounter in practice, now gets the standard semantics.

	Arnd <><

Does the linux i2o driver / subsystem work with the i2o unit
in the AMCC 460EX?  In the AMCC part it is part of the PCI-E
interface. =20

Thanks
ayman