From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 240C73858425 for ; Mon, 6 Dec 2021 18:52:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 240C73858425 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id C6E8838C720; Mon, 6 Dec 2021 13:52:33 -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 OQ0tPzPYJ2w6; Mon, 6 Dec 2021 13:52:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 2219B38C642; Mon, 6 Dec 2021 13:52:33 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 2219B38C642 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 5yxAwpGLvtvR; Mon, 6 Dec 2021 13:52:33 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 139B338C2FC; Mon, 6 Dec 2021 13:52:33 -0500 (EST) Date: Mon, 6 Dec 2021 13:52:33 -0500 (EST) From: Mathieu Desnoyers To: Florian Weimer , paulmck , Boqun Feng , Peter Zijlstra Cc: libc-alpha , linux-kernel Message-ID: <1614144911.15213.1638816753026.JavaMail.zimbra@efficios.com> In-Reply-To: <871r2podt9.fsf@oldenburg.str.redhat.com> References: <9c58724d604e160ebda5f667331fa41416c0d12b.1638798186.git.fweimer@redhat.com> <1780152866.15126.1638809966443.JavaMail.zimbra@efficios.com> <871r2podt9.fsf@oldenburg.str.redhat.com> Subject: Re: [PATCH 2/5] nptl: Add rseq registration 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_4173 (ZimbraWebClient - FF94 (Linux)/8.8.15_GA_4177) Thread-Topic: nptl: Add rseq registration Thread-Index: 9IjY+JUUfOpDSXj8/pfTcfUohvCcbQ== X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Dec 2021 18:52:36 -0000 [ Adding other kernel rseq maintainers in CC. ] ----- On Dec 6, 2021, at 12:14 PM, Florian Weimer fweimer@redhat.com wrote: > * Mathieu Desnoyers: > >> ----- On Dec 6, 2021, at 8:46 AM, Florian Weimer fweimer@redhat.com wrote: >> [...] >>> @@ -406,6 +407,9 @@ struct pthread >>> /* Used on strsignal. */ >>> struct tls_internal_t tls_state; >>> >>> + /* rseq area registered with the kernel. */ >>> + struct rseq rseq_area; >> >> The rseq UAPI requires that the fields within the rseq_area >> are read-written with single-copy atomicity semantics. >> >> So either we define a "volatile struct rseq" here, or we'll need >> to wrap all accesses with the proper volatile casts, or use the >> relaxed_mo atomic accesses. > > Under the C memory model, neither volatile nor relaxed MO result in > single-copy atomicity semantics. So I'm not sure what to make of this. > Surely switching to inline assembly on all targets is over the top. > > I think we can rely on a plain read doing the right thing for us. AFAIU, the plain read does not prevent the compiler from re-loading the value in case of high register pressure. Accesses to rseq fields such as cpu_id need to be done as if those were concurrently modified by a signal handler nesting on top of the user-space code, with the particular twist that blocking signals has no effect on concurrent updates. I do not think we need to do the load in assembly. I was under the impression that both volatile load and relaxed MO result in single-copy atomicity semantics for an aligned pointer. Perhaps Paul, Peter, Boqun have something to add here ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com