[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ye5E46FrGwjlQlps@kroah.com>
Date: Mon, 24 Jan 2022 07:19:15 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
"Paul E . McKenney" <paulmck@...nel.org>,
Boqun Feng <boqun.feng@...il.com>,
"H . Peter Anvin" <hpa@...or.com>, Paul Turner <pjt@...gle.com>,
linux-api@...r.kernel.org, stable@...r.kernel.org,
Florian Weimer <fw@...eb.enyo.de>,
Andy Lutomirski <luto@...capital.net>,
Dave Watson <davejwatson@...com>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King <linux@....linux.org.uk>,
Andi Kleen <andi@...stfloor.org>,
Christian Brauner <christian.brauner@...ntu.com>,
Ben Maurer <bmaurer@...com>,
Steven Rostedt <rostedt@...dmis.org>,
Josh Triplett <josh@...htriplett.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Michael Kerrisk <mtk.manpages@...il.com>,
Joel Fernandes <joelaf@...gle.com>
Subject: Re: [RFC PATCH] rseq: Fix broken uapi field layout on 32-bit little
endian
On Sun, Jan 23, 2022 at 02:31:54PM -0500, Mathieu Desnoyers wrote:
> The rseq rseq_cs.ptr.{ptr32,padding} uapi endianness handling is
> entirely wrong on 32-bit little endian: a preprocessor logic mistake
> wrongly uses the big endian field layout on 32-bit little endian
> architectures.
>
> Fortunately, those ptr32 accessors were never used within the kernel,
> and only meant as a convenience for user-space.
>
> While working on fixing the ppc32 support in librseq [1], I made sure
> all 32-bit little endian architectures stopped depending on little
> endian byte ordering by using the ptr32 field. It led me to discover
> this wrong ptr32 field ordering on little endian.
>
> Because it is already exposed as a UAPI, all we can do for the existing
> fields is document the wrong behavior and encourage users to use
> alternative mechanisms.
>
> Introduce a new rseq_cs.arch field with correct field ordering. Use this
> opportunity to improve the layout so accesses to architecture fields on
> both 32-bit and 64-bit architectures are done through the same field
> hierarchy, which is much nicer than the previous scheme.
>
> The intended use is now:
>
> * rseq_thread_area->rseq_cs.ptr64: Access the 64-bit value of the rseq_cs
> pointer. Available on all
> architectures (unchanged).
>
> * rseq_thread_area->rseq_cs.arch.ptr: Access the architecture specific
> layout of the rseq_cs pointer. This
> is a 32-bit field on 32-bit
> architectures, and a 64-bit field on
> 64-bit architectures.
>
> Link: https://git.kernel.org/pub/scm/libs/librseq/librseq.git/ [1]
> Fixes: ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union, update includes")
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
> Cc: Florian Weimer <fw@...eb.enyo.de>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: linux-api@...r.kernel.org
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Boqun Feng <boqun.feng@...il.com>
> Cc: Andy Lutomirski <luto@...capital.net>
> Cc: Dave Watson <davejwatson@...com>
> Cc: Paul Turner <pjt@...gle.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Russell King <linux@....linux.org.uk>
> Cc: "H . Peter Anvin" <hpa@...or.com>
> Cc: Andi Kleen <andi@...stfloor.org>
> Cc: Christian Brauner <christian.brauner@...ntu.com>
> Cc: Ben Maurer <bmaurer@...com>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Josh Triplett <josh@...htriplett.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Catalin Marinas <catalin.marinas@....com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: Michael Kerrisk <mtk.manpages@...il.com>
> Cc: Joel Fernandes <joelaf@...gle.com>
> Cc: Paul E. McKenney <paulmck@...nel.org>
> ---
> include/uapi/linux/rseq.h | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
Powered by blists - more mailing lists