From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) by sourceware.org (Postfix) with ESMTPS id 942C13858C27 for ; Wed, 8 Dec 2021 23:27:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 942C13858C27 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0F22F1A0C74; Wed, 8 Dec 2021 23:27:23 +0000 (UTC) Received: from pdx1-sub0-mail-a307.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id A2B961A0C25; Wed, 8 Dec 2021 23:27:22 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a307.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.116.149.2 (trex/6.4.3); Wed, 08 Dec 2021 23:27:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Abaft-Lonely: 6a7ff70b7d0f6153_1639006042916_4152214202 X-MC-Loop-Signature: 1639006042916:2190959230 X-MC-Ingress-Time: 1639006042915 Received: from [192.168.52.116] (unknown [223.185.2.127]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a307.dreamhost.com (Postfix) with ESMTPSA id 4J8YGw490qz3L; Wed, 8 Dec 2021 15:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1639006042; bh=zVmnr0QrEm3xM1VW+w81EviqLUs=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=vDueyjgeiGVGEUchKpuFgeEAJvgvfYitbO6BtYzt3VYaDmeVS347NOJBKQ8Sii+3o g3Z1OBNIBUFPKKgRl2lhSA0zVeit6Y74f6DoOiPyhLdffd7N3zC8oAFyIR560DYCly /z/U7PyBigPYPn/SMrVLE1s+tROcs1pKYQfQU53A= Message-ID: Date: Thu, 9 Dec 2021 04:57:15 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH 4/8] nptl: Add rseq registration Content-Language: en-US To: Florian Weimer Cc: libc-alpha@sourceware.org References: <921551c8-0cd3-5fcc-30a4-e0709485e0f1@gotplt.org> <87ilvzj7ev.fsf@oldenburg.str.redhat.com> From: Siddhesh Poyarekar In-Reply-To: <87ilvzj7ev.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3033.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Wed, 08 Dec 2021 23:27:26 -0000 On 12/8/21 23:38, Florian Weimer wrote: > * Siddhesh Poyarekar: > >>> +#ifdef RSEQ_SIG >>> +static inline void >>> +rseq_register_current_thread (struct pthread *self) >>> +{ >>> + int ret = INTERNAL_SYSCALL_CALL (rseq, >>> + &self->rseq_area, sizeof (self->rseq_area), >>> + 0, RSEQ_SIG); >>> + if (INTERNAL_SYSCALL_ERROR_P (ret)) >>> + THREAD_SETMEM (self, rseq_area.cpu_id, RSEQ_CPU_ID_REGISTRATION_FAILED); >> >> Why can't we just leave it as the kernel did when it failed the >> syscall? > > The kernel definitely won't write anything if the failure is ENOSYS. I > don't expect the kernel to write something for the other failures, > either. OK, I interpreted the from the outdated manpage patch[1] that the kernel ensures that uninitialized cpu_id will be read as -1. I read the rseq implementation in the kernel and saw that there are a number of error paths where the kernel simply returns without touching the user memory. I suppose what they meant by "uninitialized" in the manpage is actually "reset after unregister", which is odd. In any case, what I meant to eventually get at (sorry I wasn't specific; I wrote both patch reviews together and didn't realize they'd be read as separate emails!) is that RSEQ_CPU_ID_UNINITIALIZED seemed enough for all use cases and RSEQ_CPU_ID_REGISTRATION_FAILED seemed unnecessary. On syscall failure (or tunable being disabled) too it seems safe to do THREAD_SETMEM (self, rseq_area.cpu_id, RSEQ_CPU_ID_UNINITIALIZED); AFAICT, __tls_init_tp will run early enough that it won't have overwritten any earlier rseq calls from user code. Is there a use case I'm missing? Thanks, Siddhesh [1] https://lkml.org/lkml/2019/2/28/183