All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32
@ 2010-09-14 16:00 Andy Whitcroft
  2010-09-14 16:00 ` [PATCH 1/1] x86: ensure we correctly advertise 32 bit processes in a 64 bit kernel Andy Whitcroft
  2010-09-14 18:19 ` [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 H. Peter Anvin
  0 siblings, 2 replies; 4+ messages in thread
From: Andy Whitcroft @ 2010-09-14 16:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Christoph Hellwig
  Cc: x86, linux-kernel, Andy Whitcroft

While testing an x86 64 bit kernel on 32 bit userspace I noticed that I
was unexpectedly seeing x86_64 as the architecture as reported in uname.
The kernel seems to have code to detect 32 bit userspace and slam this
to i686, triggered off the personality PER_LINUX32.  However 32 bit
processes do not seem to get this flag.  I think this is an oversight.
The following patch attempts to fix this up.

-apw

Andy Whitcroft (1):
  x86: ensure we correctly advertise 32 bit processes in a 64 bit
    kernel

 arch/x86/kernel/process_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH 1/1] x86: ensure we correctly advertise 32 bit processes in a 64 bit kernel
  2010-09-14 16:00 [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 Andy Whitcroft
@ 2010-09-14 16:00 ` Andy Whitcroft
  2010-09-14 18:19 ` [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 H. Peter Anvin
  1 sibling, 0 replies; 4+ messages in thread
From: Andy Whitcroft @ 2010-09-14 16:00 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Christoph Hellwig
  Cc: x86, linux-kernel, Andy Whitcroft

A number of generic system calls modify their behaviour for 32 bit
processes when executed on a 64 bit kernel.  For example the uname
family return i686 for 32 bit processes but x86_64 for 64 bit processes.
These calls determine which return to use based on the personality,
specifically they check for PER_LINUX32.  x86 does not currently set this
personality type, using an x86 specific thread bit to distinguish.

Ensure we use personality PER_LINUX32 for 32 bit processes.

Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
 arch/x86/kernel/process_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 3d9ea53..3793a6a 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -518,7 +518,7 @@ void set_personality_ia32(void)
 
 	/* Make sure to be in 32bit mode */
 	set_thread_flag(TIF_IA32);
-	current->personality |= force_personality32;
+	current->personality |= force_personality32 | PER_LINUX32;
 
 	/* Prepare the first "return" to user space */
 	current_thread_info()->status |= TS_COMPAT;
-- 
1.7.0.4


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32
  2010-09-14 16:00 [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 Andy Whitcroft
  2010-09-14 16:00 ` [PATCH 1/1] x86: ensure we correctly advertise 32 bit processes in a 64 bit kernel Andy Whitcroft
@ 2010-09-14 18:19 ` H. Peter Anvin
  2010-09-14 18:31   ` Michael Tokarev
  1 sibling, 1 reply; 4+ messages in thread
From: H. Peter Anvin @ 2010-09-14 18:19 UTC (permalink / raw)
  To: Andy Whitcroft
  Cc: Thomas Gleixner, Ingo Molnar, Christoph Hellwig, x86, linux-kernel

On 09/14/2010 09:00 AM, Andy Whitcroft wrote:
> While testing an x86 64 bit kernel on 32 bit userspace I noticed that I
> was unexpectedly seeing x86_64 as the architecture as reported in uname.
> The kernel seems to have code to detect 32 bit userspace and slam this
> to i686, triggered off the personality PER_LINUX32.  However 32 bit
> processes do not seem to get this flag.  I think this is an oversight.
> The following patch attempts to fix this up.

No, it's not an oversight.  It's possible to hide it behind PER_LINUX32,
but that's a bigger hammer that not all users want.

	-hpa

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32
  2010-09-14 18:19 ` [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 H. Peter Anvin
@ 2010-09-14 18:31   ` Michael Tokarev
  0 siblings, 0 replies; 4+ messages in thread
From: Michael Tokarev @ 2010-09-14 18:31 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Andy Whitcroft, Thomas Gleixner, Ingo Molnar, Christoph Hellwig,
	x86, linux-kernel

14.09.2010 22:19, H. Peter Anvin wrote:
> On 09/14/2010 09:00 AM, Andy Whitcroft wrote:
>> While testing an x86 64 bit kernel on 32 bit userspace I noticed that I
[...]

Folks, while we're at it, can we also fix the ADDR_LIMIT_3GB personality?
With all current kernels it just does not work, returning EINVAL to the
second execve() call.  It never worked from within a 32bit process, but
that at least can be worked around by introducing a small 64bit helper.
Now that helper does not work too.

Or just remove it altogether, to stop confusing people... :)

(We finally moved our legacy application from oracle8 (which only exist
in 32bit for linux) to oracle10, so this problem has no relevance for
us anymore.  Before it were quite problematic...)

Thanks!

/mjt

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-09-14 18:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-09-14 16:00 [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 Andy Whitcroft
2010-09-14 16:00 ` [PATCH 1/1] x86: ensure we correctly advertise 32 bit processes in a 64 bit kernel Andy Whitcroft
2010-09-14 18:19 ` [PATCH 0/1] x86: should 32 bit processes be PER_LINUX32 H. Peter Anvin
2010-09-14 18:31   ` Michael Tokarev

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.