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 02E6AC433EF for ; Tue, 25 Jan 2022 19:01:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231605AbiAYTBB (ORCPT ); Tue, 25 Jan 2022 14:01:01 -0500 Received: from mail.efficios.com ([167.114.26.124]:51906 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229610AbiAYTAu (ORCPT ); Tue, 25 Jan 2022 14:00:50 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id EC54F34FA18; Tue, 25 Jan 2022 14:00:48 -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 5xdczh2_v_rL; Tue, 25 Jan 2022 14:00:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 8B3A834F568; Tue, 25 Jan 2022 14:00:48 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 8B3A834F568 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1643137248; bh=xG2OTorEeD0amCPtFxqQHT32yhM8ef9v4q4M9il8G7k=; h=Date:From:To:Message-ID:MIME-Version; b=JtD3PQQ94e5OxufsRH8LXTmTTVgOwXJnukhcYA7gs1L+a5UeqvuZd305VMTd5ew8s 5GxrhQ1Mx6obyvxKKPAYTDVG+2K+WRsV0POwdrPMKlwj3ADTqlV71Tu6XMJlAU2QWG YhJ3V5UwzS/5HdOll28wgL9fQpeQ/3cTXKz3E9xcZykG7RjLrn6OueGvuDxe/fLUCB lpUzoBJcVHCxFfM2lPs7S/N/3PIfQ4O8lZUcr1UQjjsduGvbhY4ImFKge70wvYMHL7 m8eci4G1P2Ps7Jg6xMt3o5U8XxFe/TqObHR8MNDsYxkXNN4ZUvEKg5en1QbetjWJQP EVrhOWRTm4twg== 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 nyPQtUQPY9hv; Tue, 25 Jan 2022 14:00:48 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 6D88334F565; Tue, 25 Jan 2022 14:00:48 -0500 (EST) Date: Tue, 25 Jan 2022 14:00:48 -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: <1445357149.71067.1643137248305.JavaMail.zimbra@efficios.com> In-Reply-To: <1234069751.70438.1643121673355.JavaMail.zimbra@efficios.com> References: <20220124171253.22072-1-mathieu.desnoyers@efficios.com> <20220124171253.22072-3-mathieu.desnoyers@efficios.com> <20220125122156.v2f5anzcs35i3rii@wittgenstein> <1234069751.70438.1643121673355.JavaMail.zimbra@efficios.com> 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+mziLmJCxydp6hDf1GHpYP Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jan 25, 2022, at 9:41 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- On Jan 25, 2022, at 7:21 AM, Christian Brauner brauner@kernel.org wrote: [...] >>> include/uapi/linux/rseq.h | 17 ++++------------- [...] >>> 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 ? Actually, if we go ahead and remove the union, and replace: struct rseq { union { __u64 ptr64; } rseq_cs; [...] } v; by: struct rseq { __u64 rseq_cs; } v; expressions such as these are unchanged: - sizeof(v.rseq_cs), - &v.rseq_cs, - __alignof__(v.rseq_cs), - offsetof(struct rseq, rseq_cs). So users of the uapi rseq.h (as an API) can still use rseq_abi->rseq_cs before and after the change. Based on this, I am inclined to remove the union, and just make the rseq_cs field a __u64. Any objections ? Thanks, Mathieu > > Thanks, > > Mathieu > > > -- > Mathieu Desnoyers > EfficiOS Inc. > http://www.efficios.com -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com