From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80B82C433F5 for ; Tue, 25 Jan 2022 14:45:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1580065AbiAYOpy (ORCPT ); Tue, 25 Jan 2022 09:45:54 -0500 Received: from mail.efficios.com ([167.114.26.124]:45014 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1579980AbiAYOla (ORCPT ); Tue, 25 Jan 2022 09:41:30 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 9EC9034DADC; Tue, 25 Jan 2022 09:41:14 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YxB3tzVOmELA; Tue, 25 Jan 2022 09:41:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 98E8434DADB; Tue, 25 Jan 2022 09:41:13 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 98E8434DADB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1643121673; bh=UHmsUtxRyc2FuICvfcuMd8VU1FfVxU1M1pUOGC/s44M=; h=Date:From:To:Message-ID:MIME-Version; b=N85YOg6In8OwsbZQpAXoK5xB8E3qIVHONNmqMtaz8WWMEkyBItYkr1GcS5kee0tmX 0bN7CP8hipq4nhJL4Jxpl4nJvaxzM2QNQG8WF6bnwEg5y/CR7Pqz7W872JFCdSsl9k q1NvEEtdYTfqMs9XqF8DOHlYsgQAz6HtjNW2mT2lb/S5LQH8LLVxzYllqb72dZw0X5 2msFMBewjejqWC40X3278ONKGm6jkRy9iv+ZD7D6BSDREBj0ZF6wz/qQ5jwMS6C7BU d4Yzz+4J4VcsLue6ukVO8qaVl+5ekmeV46WyPZ0SlyYzitmRjsdsZ2rszxBGFTcXIS lSVr9P+utpqLw== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bd4ULRnk5POI; Tue, 25 Jan 2022 09:41:13 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 7B50E34DC54; Tue, 25 Jan 2022 09:41:13 -0500 (EST) Date: Tue, 25 Jan 2022 09:41:13 -0500 (EST) From: Mathieu Desnoyers To: Christian Brauner Cc: Thomas Gleixner , linux-kernel , Peter Zijlstra , paulmck , Boqun Feng , "H. Peter Anvin" , Paul Turner , linux-api , shuah , linux-kselftest , Florian Weimer , Andy Lutomirski , Dave Watson , Andrew Morton , Russell King , Andi Kleen , Christian Brauner , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Joel Fernandes Message-ID: <1234069751.70438.1643121673355.JavaMail.zimbra@efficios.com> In-Reply-To: <20220125122156.v2f5anzcs35i3rii@wittgenstein> References: <20220124171253.22072-1-mathieu.desnoyers@efficios.com> <20220124171253.22072-3-mathieu.desnoyers@efficios.com> <20220125122156.v2f5anzcs35i3rii@wittgenstein> Subject: Re: [RFC PATCH 02/15] rseq: Remove broken uapi field layout on 32-bit little endian MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4180 (ZimbraWebClient - FF96 (Linux)/8.8.15_GA_4177) Thread-Topic: rseq: Remove broken uapi field layout on 32-bit little endian Thread-Index: jBpzgk+GT1oWkc+mziLmJCxydp6hDQ== Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org ----- On Jan 25, 2022, at 7:21 AM, Christian Brauner brauner@kernel.org wrote: > On Mon, Jan 24, 2022 at 12:12:40PM -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. >> >> Remove those and only leave the "ptr64" union field, as this is the only >> thing really needed to express the ABI. Document how 32-bit >> architectures are meant to interact with this "ptr64" union field. >> >> Fixes: ec9c82e03a74 ("rseq: uapi: Declare rseq_cs field as union, update >> includes") >> Signed-off-by: Mathieu Desnoyers >> Cc: Florian Weimer >> Cc: Thomas Gleixner >> Cc: linux-api@vger.kernel.org >> Cc: Peter Zijlstra >> Cc: Boqun Feng >> Cc: Andy Lutomirski >> Cc: Dave Watson >> Cc: Paul Turner >> Cc: Andrew Morton >> Cc: Russell King >> Cc: "H . Peter Anvin" >> Cc: Andi Kleen >> Cc: Christian Brauner >> Cc: Ben Maurer >> Cc: Steven Rostedt >> Cc: Josh Triplett >> Cc: Linus Torvalds >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: Michael Kerrisk >> Cc: Joel Fernandes >> Cc: Paul E. McKenney >> --- >> include/uapi/linux/rseq.h | 17 ++++------------- >> 1 file changed, 4 insertions(+), 13 deletions(-) >> >> diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h >> index 9a402fdb60e9..31290f2424a7 100644 >> --- a/include/uapi/linux/rseq.h >> +++ b/include/uapi/linux/rseq.h >> @@ -105,22 +105,13 @@ struct rseq { >> * Read and set by the kernel. Set by user-space with single-copy >> * atomicity semantics. This field should only be updated by the >> * thread which registered this data structure. Aligned on 64-bit. >> + * >> + * 32-bit architectures should update the low order bits of the >> + * rseq_cs.ptr64 field, leaving the high order bits initialized >> + * to 0. >> */ >> union { > > A bit unfortunate we seem to have to keep the union around even though > it's just one field now. Well, as far as the user-space projects that I know of which use rseq are concerned (glibc, librseq, tcmalloc), those end up with their own copy of the uapi header anyway to deal with the big/little endian field on 32-bit. So I'm very much open to remove the union if we accept that this uapi header is really just meant to express the ABI and is not expected to be used as an API by user-space. That would mean we also bring a uapi header copy into the kernel rseq selftests as well to minimize the gap between librseq and the kernel sefltests (the kernel sefltests pretty much include a copy of librseq for convenience. librseq is maintained out of tree). Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com