linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Paul Burton <paul.burton@mips.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Boqun Feng <boqun.feng@gmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api <linux-api@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@amacapital.net>,
	Dave Watson <davejwatson@fb.com>, Paul Turner <pjt@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Russell King <linux@arm.linux.org.uk>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>, Chris Lameter <cl@linux.com>,
	Ben Maurer <bmaurer@fb.com>, rostedt <rostedt@goodmis.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Joel Fernandes <joelaf@google.com>, shuah <shuah@kernel.org>,
	James Hogan <jhogan@kernel.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [RFC PATCH for 5.2 10/10] rseq/selftests: mips: use break instruction for RSEQ_SIG
Date: Thu, 25 Apr 2019 10:21:32 -0400 (EDT)	[thread overview]
Message-ID: <1183307732.352.1556202092390.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190424220609.4kryfcgsv46iu3ds@pburton-laptop>

----- On Apr 24, 2019, at 6:06 PM, Paul Burton paul.burton@mips.com wrote:

> Hi Mathieu,
> 
> On Wed, Apr 24, 2019 at 11:25:02AM -0400, Mathieu Desnoyers wrote:
>> diff --git a/tools/testing/selftests/rseq/rseq-mips.h
>> b/tools/testing/selftests/rseq/rseq-mips.h
>> index fe3eabcdcbe5..eb53a6adfbbb 100644
>> --- a/tools/testing/selftests/rseq/rseq-mips.h
>> +++ b/tools/testing/selftests/rseq/rseq-mips.h
>> @@ -7,7 +7,11 @@
>>   * (C) Copyright 2016-2018 - Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>>   */
>>  
>> -#define RSEQ_SIG	0x53053053
>> +/*
>> + * RSEQ_SIG uses the break instruction. The instruction pattern is
>> + *	0350000d        break    0x350
>> + */
>> +#define RSEQ_SIG	0x0350000d
> 
> My apologies for taking a while to get back to you on the various ISAs &
> endian issues here, but I think we'll want this to be something like:
> 
> #if defined(__nanomips__)
> # ifdef __MIPSEL__
> #  define RSEQ_SIG	0x03500010
> # else
> #  define RSEQ_SIG	0x00100350
> # endif
> #elif defined(__mips_micromips)
> # ifdef __MIPSEL__
> #  define RSEQ_SIG	0xd4070000
> # else
> #  define RSEQ_SIG	0x0000d407
> # endif
> #else
> # define RSEQ_SIG	0x0350000d
> #endif
> 
> For plain old MIPS the .word directive will be fine endian-wise, but for
> microMIPS & nanoMIPS we need to take into account that the instruction
> stream is encoded as 16b halfwords & swap those accordingly for little
> endian.

Considering that we have micromips and nanomips already, I guess something
along the lines of "picomips" is not that far away...

I've tried to figure out if we could find a way to have RSEQ_SIG left undefined
if it's not on the plain mips environment, but could not find anything that
would be #defined on plain mips, but #undefined on both micromips and nanomips.

What I'd like to do is e.g.:

#if defined(__nanomips__)
# ifdef __MIPSEL__
#  define RSEQ_SIG	0x03500010
# else
#  define RSEQ_SIG	0x00100350
# endif
#elif defined(__mips_micromips)
# ifdef __MIPSEL__
#  define RSEQ_SIG	0xd4070000
# else
#  define RSEQ_SIG	0x0000d407
# endif
#elif defined(__mips__)
# define RSEQ_SIG	0x0350000d
#else
/* Leave RSEQ_SIG as is. */
#endif

The idea here is to not allow code targeting future MIPS ISA to compile
with the wrong signature.

The delta between compiling without/with -mmicromips on a gcc-8 compiler
is only:

> #define __mips_micromips 1

Some interesting delta when compiling for plain little-endian mips with
gcc-8 compared to the nanomips compiler is:

< #define __mips__ 1
< #define _mips 1
< #define MIPSEL 1

> #define __nanomips__ 1

< #define __mips_isa_rev 2
> #define __mips_isa_rev 6

So let's say we have a picomips introduced in the future, can we rely
on it not defining __mips__ like the nanomips compiler does ? If so,
my "#elif defined(__mips__)" approach would indeed leave RSEQ_SIG undefined
as expected.

Thoughts ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  parent reply	other threads:[~2019-04-25 14:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 15:24 [RFC PATCH for 5.2 00/10] Restartable Sequences selftests updates Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 01/10] rseq/selftests: Add __rseq_exit_point_array section for debuggers Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 02/10] rseq/selftests: Introduce __rseq_cs_ptr_array, rename __rseq_table to __rseq_cs Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 03/10] rseq/selftests: Use __rseq_handled symbol to coexist with glibc Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 04/10] rseq/selftests: s390: use jg instruction for jumps outside of the asm Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 05/10] rseq/selftests: x86: use ud1 instruction as RSEQ_SIG opcode Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 06/10] rseq/selftests: s390: use trap4 for RSEQ_SIG Mathieu Desnoyers
2019-04-24 15:24 ` [RFC PATCH for 5.2 07/10] rseq/selftests: arm: use udf instruction " Mathieu Desnoyers
2019-04-24 15:25 ` [RFC PATCH for 5.2 08/10] rseq/selftests: aarch64 code signature: handle big-endian environment Mathieu Desnoyers
2019-04-24 16:40   ` Mark Rutland
2019-04-24 16:44     ` Will Deacon
2019-04-24 16:45     ` Mark Rutland
2019-04-24 16:45   ` Will Deacon
2019-04-24 16:51     ` Mark Rutland
2019-04-24 17:00       ` Mathieu Desnoyers
2019-04-24 17:02         ` Mathieu Desnoyers
2019-04-24 15:25 ` [RFC PATCH for 5.2 09/10] rseq/selftests: powerpc code signature: generate valid instructions Mathieu Desnoyers
2019-04-24 15:25 ` [RFC PATCH for 5.2 10/10] rseq/selftests: mips: use break instruction for RSEQ_SIG Mathieu Desnoyers
2019-04-24 22:06   ` Paul Burton
2019-04-24 23:12     ` Mathieu Desnoyers
2019-04-24 23:17       ` Paul Burton
2019-04-24 23:22         ` Mathieu Desnoyers
2019-04-25 14:21     ` Mathieu Desnoyers [this message]
2019-04-29 22:31       ` Paul Burton

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=1183307732.352.1556202092390.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=bmaurer@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=davejwatson@fb.com \
    --cc=hpa@zytor.com \
    --cc=jhogan@kernel.org \
    --cc=joelaf@google.com \
    --cc=josh@joshtriplett.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux@arm.linux.org.uk \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=paul.burton@mips.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=ralf@linux-mips.org \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).