[PATCH] ppc64: Fix PER_LINUX32 behaviour

[PATCH] ppc64: Fix PER_LINUX32 behaviour

[Paul Mackerras]

This patch fixes some bugs in the ppc64 PER_LINUX32 implementation,
noted by Juergen Kreileder:

* uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'
* Child processes of a PER_LINUX32 process don't inherit PER_LINUX32

Along the way I took the opportunity to move things around so that
sys_ppc32.c only has 32-bit syscall emulation functions and to remove
the obsolete "fakeppc" command line option.

Signed-off-by: Paul Mackerras <paulus@samba.org>
---

diff -urN linux-2.6/arch/ppc64/kernel/misc.S g5-ppc64/arch/ppc64/kernel/misc.S
--- linux-2.6/arch/ppc64/kernel/misc.S	2005-05-06 17:05:41.000000000 +1000
+++ g5-ppc64/arch/ppc64/kernel/misc.S	2005-06-08 21:56:19.000000000 +1000
@@ -792,7 +792,7 @@
 	.llong .compat_sys_newstat
 	.llong .compat_sys_newlstat
 	.llong .compat_sys_newfstat
-	.llong .sys_uname
+	.llong .sys32_uname
 	.llong .sys_ni_syscall		/* 110 old iopl syscall */
 	.llong .sys_vhangup
 	.llong .sys_ni_syscall		/* old idle syscall */
diff -urN linux-2.6/arch/ppc64/kernel/sys_ppc32.c g5-ppc64/arch/ppc64/kernel/sys_ppc32.c
--- linux-2.6/arch/ppc64/kernel/sys_ppc32.c	2005-04-26 15:37:55.000000000 +1000
+++ g5-ppc64/arch/ppc64/kernel/sys_ppc32.c	2005-06-08 21:56:19.000000000 +1000
@@ -791,31 +791,6 @@
 }
 
 
-asmlinkage int ppc64_newuname(struct new_utsname __user * name)
-{
-	int errno = sys_newuname(name);
-
-	if (current->personality == PER_LINUX32 && !errno) {
-		if(copy_to_user(name->machine, "ppc\0\0", 8)) {
-			errno = -EFAULT;
-		}
-	}
-	return errno;
-}
-
-asmlinkage int ppc64_personality(unsigned long personality)
-{
-	int ret;
-	if (current->personality == PER_LINUX32 && personality == PER_LINUX)
-		personality = PER_LINUX32;
-	ret = sys_personality(personality);
-	if (ret == PER_LINUX32)
-		ret = PER_LINUX;
-	return ret;
-}
-
-
-
 /* Note: it is necessary to treat mode as an unsigned int,
  * with the corresponding cast to a signed int to insure that the 
  * proper conversion (sign extension) between the register representation of a signed int (msr in 32-bit mode)
@@ -1158,26 +1133,47 @@
 }
 #endif
 
+asmlinkage int sys32_uname(struct old_utsname __user * name)
+{
+	int err = 0;
+	
+	down_read(&uts_sem);
+	if (copy_to_user(name, &system_utsname, sizeof(*name)))
+		err = -EFAULT;
+	up_read(&uts_sem);
+	if (!err && personality(current->personality) == PER_LINUX32) {
+		/* change "ppc64" to "ppc" */
+		if (__put_user(0, name->machine + 3)
+		    || __put_user(0, name->machine + 4))
+			err = -EFAULT;
+	}
+	return err;
+}
+
 asmlinkage int sys32_olduname(struct oldold_utsname __user * name)
 {
 	int error;
-	
-	if (!name)
-		return -EFAULT;
+
 	if (!access_ok(VERIFY_WRITE,name,sizeof(struct oldold_utsname)))
 		return -EFAULT;
   
 	down_read(&uts_sem);
 	error = __copy_to_user(&name->sysname,&system_utsname.sysname,__OLD_UTS_LEN);
-	error -= __put_user(0,name->sysname+__OLD_UTS_LEN);
-	error -= __copy_to_user(&name->nodename,&system_utsname.nodename,__OLD_UTS_LEN);
-	error -= __put_user(0,name->nodename+__OLD_UTS_LEN);
-	error -= __copy_to_user(&name->release,&system_utsname.release,__OLD_UTS_LEN);
-	error -= __put_user(0,name->release+__OLD_UTS_LEN);
-	error -= __copy_to_user(&name->version,&system_utsname.version,__OLD_UTS_LEN);
-	error -= __put_user(0,name->version+__OLD_UTS_LEN);
-	error -= __copy_to_user(&name->machine,&system_utsname.machine,__OLD_UTS_LEN);
-	error = __put_user(0,name->machine+__OLD_UTS_LEN);
+	error |= __put_user(0,name->sysname+__OLD_UTS_LEN);
+	error |= __copy_to_user(&name->nodename,&system_utsname.nodename,__OLD_UTS_LEN);
+	error |= __put_user(0,name->nodename+__OLD_UTS_LEN);
+	error |= __copy_to_user(&name->release,&system_utsname.release,__OLD_UTS_LEN);
+	error |= __put_user(0,name->release+__OLD_UTS_LEN);
+	error |= __copy_to_user(&name->version,&system_utsname.version,__OLD_UTS_LEN);
+	error |= __put_user(0,name->version+__OLD_UTS_LEN);
+	error |= __copy_to_user(&name->machine,&system_utsname.machine,__OLD_UTS_LEN);
+	error |= __put_user(0,name->machine+__OLD_UTS_LEN);
+	if (personality(current->personality) == PER_LINUX32) {
+		/* change "ppc64" to "ppc" */
+		error |= __put_user(0, name->machine + 3);
+		error |= __put_user(0, name->machine + 4);
+	}
+	
 	up_read(&uts_sem);
 
 	error = error ? -EFAULT : 0;
diff -urN linux-2.6/arch/ppc64/kernel/syscalls.c g5-ppc64/arch/ppc64/kernel/syscalls.c
--- linux-2.6/arch/ppc64/kernel/syscalls.c	2005-04-26 15:37:55.000000000 +1000
+++ g5-ppc64/arch/ppc64/kernel/syscalls.c	2005-06-07 22:33:43.000000000 +1000
@@ -199,24 +199,33 @@
 	return ret;
 }
 
-static int __init set_fakeppc(char *str)
+long ppc64_personality(unsigned long personality)
 {
-	if (*str)
-		return 0;
-	init_task.personality = PER_LINUX32;
-	return 1;
+	long ret;
+
+	if (personality(current->personality) == PER_LINUX32
+	    && personality == PER_LINUX)
+		personality = PER_LINUX32;
+	ret = sys_personality(personality);
+	if (ret == PER_LINUX32)
+		ret = PER_LINUX;
+	return ret;
 }
-__setup("fakeppc", set_fakeppc);
 
-asmlinkage int sys_uname(struct old_utsname __user * name)
+long ppc64_newuname(struct new_utsname __user * name)
 {
-	int err = -EFAULT;
-	
+	int err = 0;
+
 	down_read(&uts_sem);
-	if (name && !copy_to_user(name, &system_utsname, sizeof (*name)))
-		err = 0;
+	if (copy_to_user(name, &system_utsname, sizeof(*name)))
+		err = -EFAULT;
 	up_read(&uts_sem);
-	
+	if (!err && personality(current->personality) == PER_LINUX32) {
+		/* change ppc64 to ppc */
+		if (__put_user(0, name->machine + 3)
+		    || __put_user(0, name->machine + 4))
+			err = -EFAULT;
+	}
 	return err;
 }
 
diff -urN linux-2.6/include/asm-ppc64/elf.h g5-ppc64/include/asm-ppc64/elf.h
--- linux-2.6/include/asm-ppc64/elf.h	2005-05-02 08:29:41.000000000 +1000
+++ g5-ppc64/include/asm-ppc64/elf.h	2005-05-18 16:16:34.000000000 +1000
@@ -221,9 +221,7 @@
 		set_thread_flag(TIF_ABI_PENDING);		\
 	else							\
 		clear_thread_flag(TIF_ABI_PENDING);		\
-	if (ibcs2)						\
-		set_personality(PER_SVR4);			\
-	else if (current->personality != PER_LINUX32)		\
+	if (personality(current->personality) != PER_LINUX32)	\
 		set_personality(PER_LINUX);			\
 } while (0)
 

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Linus Torvalds]

On Wed, 8 Jun 2005, Paul Mackerras wrote:
> 
> * uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'

I think this is a feature, not a bug, and I suspect you just broke
compiling a 64-bit kernel by default on ppc64.

Dammit, the system _is_ ppc64. The fact that the uname binary is not is
neither here nor there. It's like x86 that reports i386/i486/.. depending 
on what the machine is. If uname wants to make it clear that uname has 
been compiled for 32-bit ppc, then it can damn well output "ppc" on its 
own without asking the kernel what the kernel is.

		Linus

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Arnd Bergmann]

On Middeweken 08 Juni 2005 19:24, Linus Torvalds wrote:

> I think this is a feature, not a bug, and I suspect you just broke
> compiling a 64-bit kernel by default on ppc64.
> 
> Dammit, the system _is_ ppc64. The fact that the uname binary is not is
> neither here nor there. It's like x86 that reports i386/i486/.. depending 
> on what the machine is. If uname wants to make it clear that uname has 
> been compiled for 32-bit ppc, then it can damn well output "ppc" on its 
> own without asking the kernel what the kernel is.

The whole point of the LINUX32 personality is to mangle the output of
uname, it doesn't do anything else on the architectures I have worked 
with (s390, x86_64 and ppc64).

Even with the patch, the normal operation would be to use PER_LINUX
for everything, so the kernel build works as expected unless you pass
the obsolete "fakeppc" boot parameter.

With the LINUX32 personality, you can build 32 bit binaries through
autoconf, rpmbuild, or the kernel without pretending to be
cross-compiling. It may not be the best solution, but people seem to
rely on it and the patch brings ppc64 in line with how it works on
the other architectures.

	Arnd <><

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[David S. Miller]

From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 8 Jun 2005 20:49:48 +0200

> With the LINUX32 personality, you can build 32 bit binaries through
> autoconf, rpmbuild, or the kernel without pretending to be
> cross-compiling. It may not be the best solution, but people seem to
> rely on it and the patch brings ppc64 in line with how it works on
> the other architectures.

I totally agree, this has a large precedence on many platforms
and there are even gcc frontends that check the uname output
to decide what code model to output by default.

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Andreas Schwab]

Linus Torvalds <torvalds@osdl.org> writes:

> On Wed, 8 Jun 2005, Paul Mackerras wrote:
>> 
>> * uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'
>
> I think this is a feature, not a bug, and I suspect you just broke
> compiling a 64-bit kernel by default on ppc64.

The uname syscall that Paul is referring to (__NR_olduname) isn't actually
used nowadays any more.  The current uname syscall (__NR_uname, which is
implemented by ppc64_newuname) already translates ppc64 to ppc depending
on the personality.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Olaf Hering]

 On Wed, Jun 08, David S. Miller wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 8 Jun 2005 20:49:48 +0200
> 
> > With the LINUX32 personality, you can build 32 bit binaries through
> > autoconf, rpmbuild, or the kernel without pretending to be
> > cross-compiling. It may not be the best solution, but people seem to
> > rely on it and the patch brings ppc64 in line with how it works on
> > the other architectures.
> 
> I totally agree, this has a large precedence on many platforms
> and there are even gcc frontends that check the uname output
> to decide what code model to output by default.

They (the auto* tools) should probably check for gcc -dumpmachine
instead for uname -m. Both have nothing in common, they just happen to
be equal on Walmart boxes.

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Marcus Meissner]

In article <20050608.121950.104038734.davem@davemloft.net.suse.lists.linux.kernel> you wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Wed, 8 Jun 2005 20:49:48 +0200
> 
>> With the LINUX32 personality, you can build 32 bit binaries through
>> autoconf, rpmbuild, or the kernel without pretending to be
>> cross-compiling. It may not be the best solution, but people seem to
>> rely on it and the patch brings ppc64 in line with how it works on
>> the other architectures.
> 
> I totally agree, this has a large precedence on many platforms
> and there are even gcc frontends that check the uname output
> to decide what code model to output by default.

Actually what you then do (which is the standard way) is

powerpc32 bash --login

which gives you a shell with 32bit personality and work from
this.

Ciao, Marcus

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Juergen Kreileder]

Andreas Schwab <schwab@suse.de> writes:

> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Wed, 8 Jun 2005, Paul Mackerras wrote:
>>>
>>> * uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead
>>>   of 'ppc'
>>
>> I think this is a feature, not a bug, and I suspect you just broke
>> compiling a 64-bit kernel by default on ppc64.
>
> The uname syscall that Paul is referring to (__NR_olduname) isn't
> actually used nowadays any more.  The current uname syscall
> (__NR_uname, which is implemented by ppc64_newuname) already
> translates ppc64 to ppc depending on the personality.

The current code doesn't work like intended, on my G5 both 'linux32
uname -m' and 'linux32 sh -c "uname -m"' return 'ppc64' without the
patch.
With the patch both commands return 'ppc'.


        Juergen

-- 
Juergen Kreileder, Blackdown Java-Linux Team
http://blog.blackdown.de/

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Andreas Schwab]

Juergen Kreileder <jk@blackdown.de> writes:

> The current code doesn't work like intended, on my G5 both 'linux32
> uname -m' and 'linux32 sh -c "uname -m"' return 'ppc64' without the
> patch.

You appear to be using some very old version of glibc.  I can't reproduce
that here.  Are you sure you aren't using syscall 109 (__NR_olduname)
instead of 122 (__NR_uname)?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Paul Mackerras]

Linus Torvalds writes:

> I think this is a feature, not a bug, and I suspect you just broke
> compiling a 64-bit kernel by default on ppc64.

No... I have been running with this patch for a while, and I do
actually compile up ppc64 kernels from time to time... :)

> Dammit, the system _is_ ppc64. The fact that the uname binary is not is
> neither here nor there. It's like x86 that reports i386/i486/.. depending 
> on what the machine is. If uname wants to make it clear that uname has 
> been compiled for 32-bit ppc, then it can damn well output "ppc" on its 
> own without asking the kernel what the kernel is.

Interestingly, PER_LINUX32 has nothing whatsoever to do with whether a
process is running in 32-bit or 64-bit mode.  In fact, the *only*
thing that PER_LINUX32 affects is the machine name reported by uname.
So you can have a 32-bit process without PER_LINUX32, and a 64-bit
process with PER_LINUX32.

For 32-bit processes on ppc64 we have 3 uname system calls - olduname,
uname and newuname.  For 64-bit we have just newuname.  The newuname
system call had code to return "ppc" for the machine name if the
personality was PER_LINUX32, but that code wasn't working, because it
was looking at the whole current->personality value and getting
confused if there were high bits set.  The 32-bit uname and olduname
system calls were ignoring the personality and just returning what was
in system_utsname.machine, i.e. "ppc64".  The patch makes all three
check if personality(current->personality) == PER_LINUX32 and return
"ppc" if so.

There is still a point of difference between ppc64 and x86_64: on
ppc64 (and on sparc64), if the personality is PER_LINUX32, the
personality(0xffffffffUL) system call returns PER_LINUX, and attempts
to set the personality to PER_LINUX don't change the personality
(i.e. it stays set to PER_LINUX32), for both 32-bit and 64-bit
processes.  On x86_64 this is true for 32-bit processes but not for
64-bit processes AFAICT.  Does anyone know why we do this at all, and
whether doing it for 64-bit processes makes sense?

Paul.

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Benjamin Herrenschmidt]

On Wed, 2005-06-08 at 10:24 -0700, Linus Torvalds wrote:
> 
> On Wed, 8 Jun 2005, Paul Mackerras wrote:
> > 
> > * uname(2) doesn't respect PER_LINUX32, it returns 'ppc64' instead of 'ppc'
> 
> I think this is a feature, not a bug, and I suspect you just broke
> compiling a 64-bit kernel by default on ppc64.
> 
> Dammit, the system _is_ ppc64. The fact that the uname binary is not is
> neither here nor there. It's like x86 that reports i386/i486/.. depending 
> on what the machine is. If uname wants to make it clear that uname has 
> been compiled for 32-bit ppc, then it can damn well output "ppc" on its 
> own without asking the kernel what the kernel is.

Unless I'm mistaken, 32 bits will still by default get ppc64, but this
allows us to explicitely use "linux32" binary to set personality to 32
bits, and have subprocesses of _that_ see a 32 bits uname result. That
allows dealing more easily with things like autocruft etc...

Ben.

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[David S. Miller]

From: Paul Mackerras <paulus@samba.org>
Date: Thu, 9 Jun 2005 09:12:16 +1000

> There is still a point of difference between ppc64 and x86_64: on
> ppc64 (and on sparc64), if the personality is PER_LINUX32, the
> personality(0xffffffffUL) system call returns PER_LINUX, and attempts
> to set the personality to PER_LINUX don't change the personality
> (i.e. it stays set to PER_LINUX32), for both 32-bit and 64-bit
> processes.  On x86_64 this is true for 32-bit processes but not for
> 64-bit processes AFAICT.  Does anyone know why we do this at all, and
> whether doing it for 64-bit processes makes sense?

We do this because, at least when this code was written,
glibc would do a personality(PER_LINUX) call (either via
the dynamic linker or via some other libc startup code)
and this would undo the PER_LINUX32 setting.

Therefore, it makes sense to do this for all cases, not
just for 32-bit processes.  The x86_64 code ought to be
fixed, I think.

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Linus Torvalds]

On Thu, 9 Jun 2005, Paul Mackerras wrote:
> 
> Interestingly, PER_LINUX32 has nothing whatsoever to do with whether a
> process is running in 32-bit or 64-bit mode.  In fact, the *only*
> thing that PER_LINUX32 affects is the machine name reported by uname.
> So you can have a 32-bit process without PER_LINUX32, and a 64-bit
> process with PER_LINUX32.

Ok, I stand corrected. I was assuming it got set automatically for 32-bit 
processes, without checking.

		Linus

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Juergen Kreileder]

Andreas Schwab wrote:
> Juergen Kreileder <jk@blackdown.de> writes:
>>The current code doesn't work like intended, on my G5 both 'linux32
>>uname -m' and 'linux32 sh -c "uname -m"' return 'ppc64' without the
>>patch.
> 
> You appear to be using some very old version of glibc.  I can't reproduce
> that here.  Are you sure you aren't using syscall 109 (__NR_olduname)
> instead of 122 (__NR_uname)?

Debian unstable's glibc isn't exactly new but it isn't that old.

I guess others have the seen the problem too, otherwise anybody would
have ignored my bug report and the original patch.


        Juergen

Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour

[Andi Kleen]

"David S. Miller" <davem@davemloft.net> writes:

> From: Paul Mackerras <paulus@samba.org>
> Date: Thu, 9 Jun 2005 09:12:16 +1000
>
>> There is still a point of difference between ppc64 and x86_64: on
>> ppc64 (and on sparc64), if the personality is PER_LINUX32, the
>> personality(0xffffffffUL) system call returns PER_LINUX, and attempts
>> to set the personality to PER_LINUX don't change the personality
>> (i.e. it stays set to PER_LINUX32), for both 32-bit and 64-bit
>> processes.  On x86_64 this is true for 32-bit processes but not for
>> 64-bit processes AFAICT.  Does anyone know why we do this at all, and
>> whether doing it for 64-bit processes makes sense?
5A>
> We do this because, at least when this code was written,
> glibc would do a personality(PER_LINUX) call (either via
> the dynamic linker or via some other libc startup code)
> and this would undo the PER_LINUX32 setting.
>
> Therefore, it makes sense to do this for all cases, not
> just for 32-bit processes.  The x86_64 code ought to be
> fixed, I think.

I have never seen a report of such a case (glibc undoing linux32).
Do you have details? 

But I agree 64bit should be consistent to 32bit. Will fix.

-Andi