RE: Regarding select() on PPC

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Tuesday, September 23, 2008 12:00 PM
>To: Arnd Bergmann
>Cc: linuxppc-embedded@ozlabs.org; Sadashiiv, Halesh
>Subject: Re: Regarding select() on PPC
>
>On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:
>> 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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Tue, 2008-09-23 at 12:46 +0530, Sadashiiv, Halesh wrote:
> 
> >-----Original Message-----
> >From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
> >Sent: Tuesday, September 23, 2008 12:00 PM
> >To: Arnd Bergmann
> >Cc: linuxppc-embedded@ozlabs.org; Sadashiiv, Halesh
> >Subject: Re: Regarding select() on PPC
> >
> >On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:
> >> 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.

Re: Regarding select() on PPC

[Arnd Bergmann]

On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:
> 
> > 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 <><

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Wed, 2008-09-24 at 08:23 +0200, Arnd Bergmann wrote:
> On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:
> > 
> > > 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 <><

Re: Regarding select() on PPC

[Arnd Bergmann]

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 <><

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Wed, 2008-09-24 at 08:45 +0200, Arnd Bergmann wrote:
> 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).

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.

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

> 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.

[PATCH] remove bogus ppc_select syscall

[Arnd Bergmann]

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 <halesh.sadashiv@ap.sony.com>, 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 <halesh.sadashiv@ap.sony.com>
---

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)
 {

Re: [PATCH] remove bogus ppc_select syscall

[Paul Mackerras]

Arnd Bergmann writes:

> 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)

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:

> @@ -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)

Paul.

Re: [PATCH] remove bogus ppc_select syscall

[Arnd Bergmann]

On Wednesday 24 September 2008, Paul Mackerras wrote:
> > diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/a=
sm/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)
> > =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 <><

Re: [PATCH] remove bogus ppc_select syscall

[Paul Mackerras]

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.

Re: [PATCH] remove bogus ppc_select syscall

[Arnd Bergmann]

On Friday 10 October 2008, Paul Mackerras wrote:
> Arnd Bergmann writes:
>=20
> > 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 <><

Re: [PATCH] remove bogus ppc_select syscall

[Benjamin Herrenschmidt]

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.

Re: [PATCH] remove bogus ppc_select syscall

[Paul Mackerras]

Benjamin Herrenschmidt writes:

> 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 ?

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.

Re: [PATCH] remove bogus ppc_select syscall

[Arnd Bergmann]

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>

Re: [PATCH] remove bogus ppc_select syscall

[Benjamin Herrenschmidt]

On Fri, 2008-10-10 at 18:43 +1100, Paul Mackerras wrote:
> > 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.

Re: [PATCH] remove bogus ppc_select syscall

[Arnd Bergmann]

On Saturday 11 October 2008, Benjamin Herrenschmidt wrote:
> > 
> > -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 <><

i2o driver work with AMCC 460EX?

[Ayman El-Khashab]

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

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Tuesday, September 23, 2008 2:38 PM
>To: Sadashiiv, Halesh
>Cc: Arnd Bergmann; linuxppc-embedded@ozlabs.org
>Subject: RE: Regarding select() on PPC
>
>On Tue, 2008-09-23 at 12:46 +0530, Sadashiiv, Halesh wrote:
>>
>> >-----Original Message-----
>> >From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>> >Sent: Tuesday, September 23, 2008 12:00 PM
>> >To: Arnd Bergmann
>> >Cc: linuxppc-embedded@ozlabs.org; Sadashiiv, Halesh
>> >Subject: Re: Regarding select() on PPC
>> >
>> >On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:
>> >> 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
>

Ok, directly sys_select() can be called instead of wrappers.

>Ben.
>
>

Halesh


-------------------------------------------------------------------
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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Tuesday, September 23, 2008 10:41 AM
>To: Sadashiiv, Halesh
>Cc: Josh Boyer; linuxppc-embedded@ozlabs.org
>Subject: RE: Regarding select() on PPC
>
>
>> >Your patch should be submitted to the linuxppc-dev mailing list btw.
>> >
>>
>> Will do that.
>
>Don't bother for now. The right approach would be to just
>get rid of the wrappers I believe. I'm sorting that out.
>

Ok.Will wait, thanks a lot

>Ben.
>
>


Halesh


-------------------------------------------------------------------
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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Tuesday, September 23, 2008 10:26 AM
>To: Sadashiiv, Halesh
>Cc: Josh Boyer; linuxppc-embedded@ozlabs.org
>Subject: RE: Regarding select() on PPC
>
>On Tue, 2008-09-23 at 10:20 +0530, Sadashiiv, Halesh wrote:
>> Hi,
>>
>> The below testcase requires to exit with setting errno as EINVAL, as
per
>> the man page.
>>
>> I tested this on ARM, I686, PPC64 it was fine, for the same on PPC32
it
>> used exit with errno set as EFAULT.
>>
>> On further investigation found there was some long obsolete code in
>> arch/powerpc/kernel/syscalls.c (function ppc_select()), which was
>> written in 2.2.0 kernel for PPC32 specific , which resulted in
EFAULT.
>>
>> This needs to be verified, I have proposed patch for PPC32, Please
check
>> the link
>> http://article.gmane.org/gmane.linux.kernel/735922
>>
>
>I'm trying to sort out how obsolete it actually is and see if we can
>remove the whole thing.
>

Ok...once you verified please let me know.


>Your patch should be submitted to the linuxppc-dev mailing list btw.
>

Will do that.

>Ben.
>
>

Thanks,
Halesh


-------------------------------------------------------------------
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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Benjamin Herrenschmidt]

> >Your patch should be submitted to the linuxppc-dev mailing list btw.
> >
> 
> Will do that.

Don't bother for now. The right approach would be to just
get rid of the wrappers I believe. I'm sorting that out.

Ben.

Re: Regarding select() on PPC

[Arnd Bergmann]

On Tuesday 23 September 2008, Sadashiiv, Halesh wrote:
> 
> >I'm trying to sort out how obsolete it actually is and see if we can
> >remove the whole thing.
> >
> 
> Ok...once you verified please let me know.
> 

I just did some more research. The bug was introduced with Linux-2.1.48,
the same version in which Pauls name first appeared as the PPC guy
in the MAINTAINERS file, over 11 years ago.

Before that, ppc used to have distinct implementations for oldselect
(__NR_select) and select (__NR__newselect), because initially it shared
the syscall numbers with i386 and that had replaced its oldselect
with newselect in 1.3.0.

In essence, oldselect was already obsolete before it was introduced
in the powerpc architecture, but for obscure reasons, some code
must have confused the two calling conventions, so Cort introduced
the wrapper that could handle either one, and used it for both
syscalls. This of course made it theoretically impossible to ever
fix the implementation without potentially breaking user space one
way or another.

The 32 bit emulation code never implemented a call behind __NR_select
or the oldselect calling conventions, so anything relying on
the legacy behaviour is broken there already.

I would definitely switch over the ppc32 __NR_newselect implementation
to sys_select. For __NR_select, there is no correct solution, the three
options are the current ppc_select, the real sys_select or sys_ni_syscall.
Each of these is broken in different ways, but in practice it will never
be called anyway.

I love archeology.

	Arnd <><

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Tue, 2008-09-23 at 07:46 +0200, Arnd Bergmann wrote:
> I would definitely switch over the ppc32 __NR_newselect implementation
> to sys_select. For __NR_select, there is no correct solution, the three
> options are the current ppc_select, the real sys_select or sys_ni_syscall.
> Each of these is broken in different ways, but in practice it will never
> be called anyway.
> 
> I love archeology.

Any idea when glibc got fixed ?

Ben

Re: Regarding select() on PPC

[Arnd Bergmann]

On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:
> On Tue, 2008-09-23 at 07:46 +0200, Arnd Bergmann wrote:
> > I would definitely switch over the ppc32 __NR_newselect implementation
> > to sys_select. For __NR_select, there is no correct solution, the three
> > options are the current ppc_select, the real sys_select or sys_ni_syscall.
> > Each of these is broken in different ways, but in practice it will never
> > be called anyway.
> > 
> > I love archeology.
> 
> Any idea when glibc got fixed ?
> 

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.

	Arnd <><

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Tue, 2008-09-23 at 08:01 +0200, Arnd Bergmann wrote:
> 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.

Ben.

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

Hi,

The below testcase requires to exit with setting errno as EINVAL, as per
the man page.

I tested this on ARM, I686, PPC64 it was fine, for the same on PPC32 it
used exit with errno set as EFAULT.

On further investigation found there was some long obsolete code in
arch/powerpc/kernel/syscalls.c (function ppc_select()), which was
written in 2.2.0 kernel for PPC32 specific , which resulted in EFAULT.

This needs to be verified, I have proposed patch for PPC32, Please check
the link
http://article.gmane.org/gmane.linux.kernel/735922


Please find the below testcase.

#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <time.h>
#include <errno.h>
#include <stdlib.h>

int main()
{

 int fd;
 fd_set rfds;
 struct timeval tv;
 int ret_val;

 if ((fd =3D open("test_file", O_RDWR|O_CREAT, 0664)) < 0)
  {
    printf("Open failed\n");
  }

  FD_ZERO(&rfds);
  FD_SET(fd, &rfds);

  /* Wait up to five seconds. */
  tv.tv_sec =3D 1;
  tv.tv_usec =3D 0;

  if ( (ret_val =3D select(-1, &rfds, NULL, NULL, &tv)) < 0)
  {
    if ( errno =3D=3D EINVAL)
      printf("OK\n");
    else
      printf("Not OK, Got errno %d\n", errno);
  }
  exit(0);
}


Thanks,
Halesh



>-----Original Message-----
>From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
>Sent: Tuesday, September 23, 2008 10:12 AM
>To: Josh Boyer
>Cc: Sadashiiv, Halesh; linuxppc-embedded@ozlabs.org
>Subject: Re: Regarding select() on PPC
>
>On Mon, 2008-09-22 at 11:24 -0400, Josh Boyer wrote:
>> On Mon, Sep 22, 2008 at 08:45:52PM +0530, Sadashiiv, Halesh wrote:
>> >
>> >
>> >The issue is found only in PPC32.
>> >
>> >Please let me if the patch is applicable.
>>
>> Well, no not really.  Mostly because of procedural issues than
anything
>> else.  Read Documentation/SubmittingPatches in the kernel directory.
>>
>> Also, there is a comment above this function that eludes to some
issues
>> with select on ppc32.  You might want to ask the overall PowerPC
>maintainer
>> if that issue still exits.
>
>I have only half of this thread, what is the problem ?
>
>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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Tue, 2008-09-23 at 10:20 +0530, Sadashiiv, Halesh wrote:
> Hi,
> 
> The below testcase requires to exit with setting errno as EINVAL, as per
> the man page.
> 
> I tested this on ARM, I686, PPC64 it was fine, for the same on PPC32 it
> used exit with errno set as EFAULT.
> 
> On further investigation found there was some long obsolete code in
> arch/powerpc/kernel/syscalls.c (function ppc_select()), which was
> written in 2.2.0 kernel for PPC32 specific , which resulted in EFAULT.
> 
> This needs to be verified, I have proposed patch for PPC32, Please check
> the link
> http://article.gmane.org/gmane.linux.kernel/735922
> 

I'm trying to sort out how obsolete it actually is and see if we can
remove the whole thing.

Your patch should be submitted to the linuxppc-dev mailing list btw.

Ben.

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

Thanks for the quick reply...

>-----Original Message-----
>From: Josh Boyer [mailto:jwboyer@gmail.com]
>Sent: Monday, September 22, 2008 8:55 PM
>To: Sadashiiv, Halesh
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: Regarding select() on PPC
>
>On Mon, Sep 22, 2008 at 08:45:52PM +0530, Sadashiiv, Halesh wrote:
>>
>>
>>The issue is found only in PPC32.
>>
>>Please let me if the patch is applicable.
>
>Well, no not really.  Mostly because of procedural issues than anything
>else.  Read Documentation/SubmittingPatches in the kernel directory.

Will check the details.

>
>Also, there is a comment above this function that eludes to some issues
>with select on ppc32.  You might want to ask the overall PowerPC
maintainer
>if that issue still exits.

I have also posted in http://news.gmane.org/gmane.linux.kernel

http://article.gmane.org/gmane.linux.kernel/735618

Still no reply from any maintainer.

>
>josh


- Halesh



-------------------------------------------------------------------
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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

The issue is found only in PPC32.

Please let me if the patch is applicable.

+++ arch/powerpc/kernel/syscalls.c      2008-09-22 20:47:23.885126056
+0530
@@ -211,6 +211,9 @@
 int
 ppc_select(int n, fd_set __user *inp, fd_set __user *outp, fd_set
__user *exp, struct timeval __user *tvp)
 {
+   if ( n < 0 )
+       return -EINVAL;
+
    if ( (unsigned long)n >=3D 4096 )
    {
        unsigned long __user *buffer =3D (unsigned long __user *)n;

Thanks,
Halesh


>-----Original Message-----
>From: Josh Boyer [mailto:jwboyer@gmail.com]
>Sent: Friday, September 19, 2008 7:49 PM
>To: Sadashiiv, Halesh
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: Regarding select() on PPC
>
>On Fri, Sep 19, 2008 at 07:00:07PM +0530, Sadashiiv, Halesh wrote:
>>>For negetive value of n (first argument to select) select fails with
>>EINVAL
>>>error,
>>>
>>>But for the same when I tested for PowerPC it was giving EFAULT,
>>>Its on 2.6.16 kernel.
>
>2.6.16 is really old.  I tested your testcase on a 2.6.25 based kernel
on
>a ppc64 machine and it seemed to work fine.
>
>josh



-------------------------------------------------------------------
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.
-------------------------------------------------------------------

Re: Regarding select() on PPC

[Josh Boyer]

On Mon, Sep 22, 2008 at 08:45:52PM +0530, Sadashiiv, Halesh wrote:
>
>
>The issue is found only in PPC32.
>
>Please let me if the patch is applicable.

Well, no not really.  Mostly because of procedural issues than anything
else.  Read Documentation/SubmittingPatches in the kernel directory.

Also, there is a comment above this function that eludes to some issues
with select on ppc32.  You might want to ask the overall PowerPC maintainer
if that issue still exits.

josh

Re: Regarding select() on PPC

[Benjamin Herrenschmidt]

On Mon, 2008-09-22 at 11:24 -0400, Josh Boyer wrote:
> On Mon, Sep 22, 2008 at 08:45:52PM +0530, Sadashiiv, Halesh wrote:
> >
> >
> >The issue is found only in PPC32.
> >
> >Please let me if the patch is applicable.
> 
> Well, no not really.  Mostly because of procedural issues than anything
> else.  Read Documentation/SubmittingPatches in the kernel directory.
> 
> Also, there is a comment above this function that eludes to some issues
> with select on ppc32.  You might want to ask the overall PowerPC maintainer
> if that issue still exits.

I have only half of this thread, what is the problem ?

Ben.

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Josh Boyer [mailto:jwboyer@gmail.com]
>Sent: Friday, September 19, 2008 7:49 PM
>To: Sadashiiv, Halesh
>Cc: linuxppc-embedded@ozlabs.org
>Subject: Re: Regarding select() on PPC
>
>On Fri, Sep 19, 2008 at 07:00:07PM +0530, Sadashiiv, Halesh wrote:
>>>For negetive value of n (first argument to select) select fails with
>>EINVAL
>>>error,
>>>
>>>But for the same when I tested for PowerPC it was giving EFAULT,
>>>Its on 2.6.16 kernel.
>
>2.6.16 is really old.  I tested your testcase on a 2.6.25 based kernel
on
>a ppc64 machine and it seemed to work fine.
>
>josh


Thanks for the info,

I am using PPC32, I think it doest not matters on 2.6.16 as I manually
checked the select source with 2.6.23 and no changes seen.
&
Even the same testcase passes on MIPS32 with 2.6.16.

Thanks
Halesh




-------------------------------------------------------------------
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.
-------------------------------------------------------------------

RE: Regarding select() on PPC

[Sadashiiv, Halesh]

>-----Original Message-----
>From: Sadashiiv, Halesh
>Sent: Friday, September 19, 2008 5:21 PM
>To: 'linuxppc-embedded@ozlabs.org'
>Subject: Regarding select() on PPC
>
>
>Hi all,
>
>Please find the below testcase.
>
>#include <stdio.h>
>#include <sys/time.h>
>#include <sys/types.h>
>#include <unistd.h>
>#include <fcntl.h>
>#include <string.h>
>#include <time.h>
>#include <errno.h>
>#include <stdlib.h>
>
>int main()
>{
>
> int fd;
> fd_set rfds;
> struct timeval tv;
> int ret_val;
>
> if ((fd =3D open("test_file", O_RDWR|O_CREAT, 0664)) < 0)
>  {
>    printf("Open failed\n");
>  }
>
>  FD_ZERO(&rfds);
>  FD_SET(fd, &rfds);
>
>  /* Wait up to five seconds. */
>  tv.tv_sec =3D 1;
>  tv.tv_usec =3D 0;
>
>  if ( (ret_val =3D select(-1, &rfds, NULL, NULL, &tv)) < 0)
>  {
>    if ( ret_val =3D=3D EINVAL)
=09
	if ( errno =3D=3D EINVAL)
Need to change it to errno, still not works.

>      printf("OK\n");
>    else
>      printf("Not OK, Got errno %d\n", errno);
>  }
>  exit(0);
>}
>
>
>For negetive value of n (first argument to select) select fails with
EINVAL
>error,
>
>But for the same when I tested for PowerPC it was giving EFAULT,
>Its on 2.6.16 kernel.
>
>Please let me know, If this is fixed or it's a issue in PPC.
>For other archs its working fine.
>
>
>Thanks,
>Halesh
>
>
>



-------------------------------------------------------------------
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.
-------------------------------------------------------------------

Re: Regarding select() on PPC

[Josh Boyer]

On Fri, Sep 19, 2008 at 07:00:07PM +0530, Sadashiiv, Halesh wrote:
>>For negetive value of n (first argument to select) select fails with
>EINVAL
>>error,
>>
>>But for the same when I tested for PowerPC it was giving EFAULT,
>>Its on 2.6.16 kernel.

2.6.16 is really old.  I tested your testcase on a 2.6.25 based kernel on
a ppc64 machine and it seemed to work fine.

josh

Regarding select() on PPC

[Sadashiiv, Halesh]

Hi all,

Please find the below testcase.

#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>
#include <string.h>
#include <time.h>
#include <errno.h>
#include <stdlib.h>

int main()
{

 int fd;
 fd_set rfds;
 struct timeval tv;
 int ret_val;

 if ((fd =3D open("test_file", O_RDWR|O_CREAT, 0664)) < 0)
  {
    printf("Open failed\n");
  }

  FD_ZERO(&rfds);
  FD_SET(fd, &rfds);

  /* Wait up to five seconds. */
  tv.tv_sec =3D 1;
  tv.tv_usec =3D 0;

  if ( (ret_val =3D select(-1, &rfds, NULL, NULL, &tv)) < 0)
  {
    if ( ret_val =3D=3D EINVAL)
      printf("OK\n");
    else
      printf("Not OK, Got errno %d\n", errno);
  }
  exit(0);
}


For negetive value of n (first argument to select) select fails with
EINVAL error,

But for the same when I tested for PowerPC it was giving EFAULT,=20
Its on 2.6.16 kernel.

Please let me know, If this is fixed or it's a issue in PPC.
For other archs its working fine.


Thanks,
Halesh






-------------------------------------------------------------------
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.
-------------------------------------------------------------------

Re: Regarding select() on PPC

[Dale Farnsworth]

> For negetive value of n (first argument to select) select fails with
> EINVAL error,
> 
> But for the same when I tested for PowerPC it was giving EFAULT, 
> Its on 2.6.16 kernel.
> 
> Please let me know, If this is fixed or it's a issue in PPC.
> For other archs its working fine.

Interesting.  The man page for select says that select should return
EINVAL when the first argument is negative.  By that, only ppc32 is
correct.  :)

-Dale

Re: Regarding select() on PPC

[Dale Farnsworth]

I wrote:
> Interesting.  The man page for select says that select should return
> EINVAL when the first argument is negative.  By that, only ppc32 is
> correct.  :)

Sorry.  I should read before posting.  Please ignore my extraneous
comment above.

-Dale