Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4530627pxb; Tue, 25 Jan 2022 12:24:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJzWjYxdcl62CEx0a5vnww4S5ZqdgiMLvxe9aX91itiIQ45kBuEHVCqpy31XW/SWUr26EFYo X-Received: by 2002:a17:902:9343:b0:148:a2e8:2c49 with SMTP id g3-20020a170902934300b00148a2e82c49mr20742745plp.152.1643142258351; Tue, 25 Jan 2022 12:24:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643142258; cv=none; d=google.com; s=arc-20160816; b=ky+U3Xxsvxxikfv0Je7e/Syp6pcEsC0fkaqB4FyCOOBFwIEjP6BYSN8ZcTu+s+LW7Y 04Cs9bqCo6aZw/AXfm4CwO5ZGaftCZ18psGfELA/do86YMrfYNfje4MgCGu6HMio/eQf qR/cRtr6nDvWJBfWGfHWE7407mv/tXbP0nCGYUjBgQd7XhFD0x6fStMpyhh/CRsaZMAP i0MPywkqkrD3hhFs7PNSlJ1OWD7iMLJdJv1bjUbBFLwOjY/pVhmOngmge5HjMFxoWHH9 ptD/CU95rwufXRtiO7/5JPt64lecI/lUB8wtXe7fmD5gEYL51TvBQ3wxlJ5e9oHzIJtU U7tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=UHmsUtxRyc2FuICvfcuMd8VU1FfVxU1M1pUOGC/s44M=; b=XxB4Q++YVoloLpqIYBmTqPmPW02DfGAU4C5FyOlUofRUKdCYcWyOVgIQ7DbMoQPgtt DuwJZkURM6YoyvEtFVFCOdfpCokXCLIzWX6XQ+RE7ZOURcSVpnmboye+NWwJXajKTT5s qm6L25btsqDCB6cSL4yb4CnnXh4yTfEnZjWuZXmmXJ3O4sSDAE1t4nLfE8YWdMaHA065 U6q1qwaHYKCMtE0KkpaoUZtxF2wTBkFUSqjbupkKUNYqkR1qpg/CWJRYLBWSrm5H98br OdX6HD/CovsMoz9LGsHT9BJwclQdiiyJ6pCPaA3p58UO+XnksDlIhqBd/8hW1t4spwxX 5KYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=N85YOg6I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v12si1143854pjn.7.2022.01.25.12.24.06; Tue, 25 Jan 2022 12:24:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=N85YOg6I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1580280AbiAYOpw (ORCPT + 99 others); Tue, 25 Jan 2022 09:45:52 -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-kernel@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