All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: "David S. Miller" <davem@davemloft.net>
Cc: torvalds@osdl.org, akpm@osdl.org, anton@samba.org,
	linux-kernel@vger.kernel.org, jk@blackdown.de
Subject: Re: [PATCH] ppc64: Fix PER_LINUX32 behaviour
Date: Sat, 11 Jun 2005 13:24:50 +0200	[thread overview]
Message-ID: <m1slzpcf0d.fsf@muc.de> (raw)
In-Reply-To: <20050608.161633.55509444.davem@davemloft.net> (David S. Miller's message of "Wed, 08 Jun 2005 16:16:33 -0700 (PDT)")

"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


  reply	other threads:[~2005-06-11 11:24 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-08 11:59 [PATCH] ppc64: Fix PER_LINUX32 behaviour Paul Mackerras
2005-06-08 17:24 ` Linus Torvalds
2005-06-08 18:49   ` Arnd Bergmann
2005-06-08 19:19     ` David S. Miller
2005-06-08 20:45       ` Olaf Hering
2005-06-08 20:45   ` Andreas Schwab
2005-06-08 20:54     ` Juergen Kreileder
2005-06-08 22:40       ` Andreas Schwab
2005-06-09  7:02         ` Juergen Kreileder
2005-06-08 23:12   ` Paul Mackerras
2005-06-08 23:16     ` David S. Miller
2005-06-11 11:24       ` Andi Kleen [this message]
2005-06-08 23:28     ` Linus Torvalds
2005-06-08 23:12   ` Benjamin Herrenschmidt
     [not found] <20050608.121950.104038734.davem@davemloft.net.suse.lists.linux.kernel>
2005-06-08 20:50 ` Marcus Meissner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1slzpcf0d.fsf@muc.de \
    --to=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=anton@samba.org \
    --cc=davem@davemloft.net \
    --cc=jk@blackdown.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.