All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikola Veljkovic <Nikola.Veljkovic@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Chris Dearman <Chris.Dearman@imgtec.com>,
	"Raghu Gandham" <Raghu.Gandham@imgtec.com>,
	Miodrag Dinic <Miodrag.Dinic@imgtec.com>,
	Petar Jovanovic <Petar.Jovanovic@imgtec.com>,
	Lazar Trsic <Lazar.Trsic@imgtec.com>
Subject: RE: [PATCH] MIPS: personality syscall discrepancy on mips64-o32/n32
Date: Thu, 12 Nov 2015 19:50:26 +0000	[thread overview]
Message-ID: <19CDB9880DBFC241860D925D8FAA94A024A0AFBA@BADAG02.ba.imgtec.org> (raw)
In-Reply-To: <20151112162529.GF29184@linux-mips.org>

>For anything that changes an established ABI - in this case for about 15 or
>16 years I'm going to be conservative at changing such an ABI.  Also Sparc64
>and PowerPC are using the exactly same wrapper.

>Anyway, can you tell me more about the Android issue?

I started the discussion after Google updated personality test in bionic [1].
Test expects the PER_LINUX32 to be returned for a 32-bit binary, so it fails
on mips64 for 32bit binaries.
https://android-review.googlesource.com/#/c/157455/1/tests/sys_personality_test.cpp

My guess was that the changes in test were going to be followed with the code
dependent on the personality syscall elsewhere, but so far that did not happen.
Only user of the personality syscall in Android is strace, and there are no 
issues with it as far as I know.

Also, my understanding of the risks the change in kernel would create was wrong.
From this perspective I believe your arguments against the kernel change to be
sufficient for me to propose to Google a change in the personality test.

Thank you for the additional info,
Nikola
________________________________________
From: Ralf Baechle [ralf@linux-mips.org]
Sent: Thursday, November 12, 2015 5:25 PM
To: Nikola Veljkovic
Cc: Markos Chandras; linux-mips@linux-mips.org; Chris Dearman; Raghu Gandham; Miodrag Dinic; Petar Jovanovic; Lazar Trsic
Subject: Re: [PATCH] MIPS: personality syscall discrepancy on mips64-o32/n32

On Thu, Aug 20, 2015 at 02:46:26PM +0000, Nikola Veljkovic wrote:

>  > I am not sure what the implication will be to userland with that change...
> I could not find any code that explicitly checks for PER_LINUX[32]. Of course,
> I might be missing something. Any suspects?

The one thing where it really matters is the architecture return value
for uname, try "uname -m".  On a 32 bit kernel this will return "mips",
on a 64 bit kernel "mips64".  This will break some software that expects
to identify MIPS by "mips".  There's a small tool to set this personality
flag, see ftp://ftp.linux-mips.org/pub/linux/mips/mips32/ for a year 2000
vintage source and binary rpm.  Or also the more modern setarch(1) utility.

>  > I presume you also need to fix the n32 case and then completely remove the
>  > sys_32_personality syscall from linux32.c.
> New patch below removes the syscall.
>
>  > Moreover, I think you also need to fix the arch/mips/include/asm/elf.h
>  > code to set LINUX32 for O32 and n32 (for both 32b and 64b kernels.)
> Other archs (arm, intel) do not do that, so I think we should follow, and set
> PER_LINUX, but let userspace change this if it wants to. On the kernel side this
> only affects uname. From the discussion [1] it seems like the right way to go.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/114506.html

x86 and ARM maybe but not SPARC64 which uses the exactly same code,
see arch/sparc/kernel/sys_sparc_64.c function sparc64_personality() and
from which this function and the mips32 utility which was named sparc32
in a former live, were taken.

The PER_LINUX32 -> PER_LINUX translation of the return value is for antique
programs that expect to see PER_LINUX as the return value.

> Tested changing only o32 on Android, there were no regressions:

For anything that changes an established ABI - in this case for about 15 or
16 years I'm going to be conservative at changing such an ABI.  Also Sparc64
and PowerPC are using the exactly same wrapper.

Anyway, can you tell me more about the Android issue?

  Ralf

WARNING: multiple messages have this Message-ID
From: Nikola Veljkovic <Nikola.Veljkovic@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Markos Chandras <Markos.Chandras@imgtec.com>,
	"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
	Chris Dearman <Chris.Dearman@imgtec.com>,
	Raghu Gandham <Raghu.Gandham@imgtec.com>,
	Miodrag Dinic <Miodrag.Dinic@imgtec.com>,
	Petar Jovanovic <Petar.Jovanovic@imgtec.com>,
	Lazar Trsic <Lazar.Trsic@imgtec.com>
Subject: RE: [PATCH] MIPS: personality syscall discrepancy on mips64-o32/n32
Date: Thu, 12 Nov 2015 19:50:26 +0000	[thread overview]
Message-ID: <19CDB9880DBFC241860D925D8FAA94A024A0AFBA@BADAG02.ba.imgtec.org> (raw)
Message-ID: <20151112195026.AmFdBMo2__Hc8N75LuEcSK1CVfpThSNsZsAWqPRBuOs@z> (raw)
In-Reply-To: <20151112162529.GF29184@linux-mips.org>

>For anything that changes an established ABI - in this case for about 15 or
>16 years I'm going to be conservative at changing such an ABI.  Also Sparc64
>and PowerPC are using the exactly same wrapper.

>Anyway, can you tell me more about the Android issue?

I started the discussion after Google updated personality test in bionic [1].
Test expects the PER_LINUX32 to be returned for a 32-bit binary, so it fails
on mips64 for 32bit binaries.
https://android-review.googlesource.com/#/c/157455/1/tests/sys_personality_test.cpp

My guess was that the changes in test were going to be followed with the code
dependent on the personality syscall elsewhere, but so far that did not happen.
Only user of the personality syscall in Android is strace, and there are no 
issues with it as far as I know.

Also, my understanding of the risks the change in kernel would create was wrong.

  reply	other threads:[~2015-11-12 19:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 10:25 [PATCH] MIPS: personality syscall discrepancy on mips64-o32/n32 Nikola Veljkovic
2015-08-18 10:25 ` Nikola Veljkovic
2015-08-18 12:56 ` Markos Chandras
2015-08-20 14:46   ` Nikola Veljkovic
2015-08-20 14:46     ` Nikola Veljkovic
2015-11-12 16:25     ` Ralf Baechle
2015-11-12 19:50       ` Nikola Veljkovic [this message]
2015-11-12 19:50         ` Nikola Veljkovic

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=19CDB9880DBFC241860D925D8FAA94A024A0AFBA@BADAG02.ba.imgtec.org \
    --to=nikola.veljkovic@imgtec.com \
    --cc=Chris.Dearman@imgtec.com \
    --cc=Lazar.Trsic@imgtec.com \
    --cc=Markos.Chandras@imgtec.com \
    --cc=Miodrag.Dinic@imgtec.com \
    --cc=Petar.Jovanovic@imgtec.com \
    --cc=Raghu.Gandham@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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.