From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 691633821FE7 for ; Fri, 16 Sep 2022 21:32:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 691633821FE7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=deneb.enyo.de Received: from [172.17.203.2] (port=37937 helo=deneb.enyo.de) by albireo.enyo.de ([172.17.140.2]) with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) id 1oZIwx-001rPY-2w; Fri, 16 Sep 2022 21:32:39 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.94.2) (envelope-from ) id 1oZIww-0007WH-O5; Fri, 16 Sep 2022 23:32:38 +0200 From: Florian Weimer To: Chris Kennelly Cc: libc-coord@lists.openwall.com, Mathieu Desnoyers , "carlos@redhat.com" , libc-alpha , szabolcs.nagy@arm.com Subject: Re: [libc-coord] Re: RSEQ symbols: __rseq_size, __rseq_flags vs __rseq_feature_size References: <87y1uj49t4.fsf@mid.deneb.enyo.de> Date: Fri, 16 Sep 2022 23:32:38 +0200 In-Reply-To: (Chris Kennelly's message of "Fri, 16 Sep 2022 11:41:39 -0400") Message-ID: <87fsgryphl.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Chris Kennelly: >> If the kernel does not currently overwrite the padding, glibc can do >> its own per-thread initialization there to support its malloc >> implementation (because the padding is undefined today from an >> application perspective). That is, we would initialize these >> invisible vCPU IDs the same way we assign arenas today. That would >> cover this specific malloc use case only, of course. > If a user program updates to a new kernel before glibc does, would it be > able to easily take advantage of it? No, as far as I understand it, there is presently no signaling from kernel to applications that bypasses the rseq area registration. So the only thing you could do is to unregister and re-register with a compatible value. And that is of course quite undefined and assumes that you can do this early enough during the life-time of each thread. But if we have the extension handshake, I'll expect us to backport it quite widely, after some time to verify that it works with CRIU etc.