From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13417 invoked from network); 16 Feb 2022 19:56:31 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Feb 2022 19:56:31 -0000 Received: (qmail 1597 invoked by uid 550); 16 Feb 2022 19:56:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1574 invoked from network); 16 Feb 2022 19:56:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645041376; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OAWhQ1WnUFEKnSGRjCesaxlTusNCqsR0eueBmLD1hR8=; b=WHTT6hSZ29mu1Hb9Jec7N6WFOP1il7NIa74g83HSmKEkXv+HMIrBCnCDg8WXw5fGy/rYkF DMuDewyCxiA3yki4oB7V5kCQhgpzi0+gtDu3inMNXVsn5S60os8iprxrCXtkkjcElCCh3U BWdngS+dgC6izvj/P2Zeyts+vHIxiNo= X-MC-Unique: lvFjpSguO4mOmF0X3Ro4Ow-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:organization:in-reply-to :content-transfer-encoding; bh=OAWhQ1WnUFEKnSGRjCesaxlTusNCqsR0eueBmLD1hR8=; b=SpGzMlwTioFcvzwsZKeUNOxm7v7J+AyFCXn4SdGd/Vs44MBuHYsDyTmIoIybEjIDgU NfltQ20nqLXIxjtENMuxvrbD9zImWoOQNtM/RbwCaLaP+IAX6CRtRUgDKAw9Jx7gRq29 bJapk5Mb0mZ6tVz0w/cEXnTggBzIB/uEtXqZIpWjj0jX0gf7G84ScTQ6R2DpIglvIQ03 F9nPNP9xgIJzJRfvJ7HfHnToWr26UJ6BhmZRWiuuOCIv05IesSIGYS+NDDmUWcC9A2kL oNGR2sx+r466fxX6t9AK6IGMBphGMo22XmZjX/uJrZr39ne+P5qrNb1zcx168ZzaZfOS /cyA== X-Gm-Message-State: AOAM530lSFfAkcZ4gudQLSbvbg99IiAphbrrjiW8F2w0h9bSaTMwJ67W zYVY1I5/u71xWBNenIkKWPSGvV4Uf4Ql5zgJvFNpGUmTT515vKH0UC2klYmhEF2AxgjPWrOIwdr x2DNFEqVuu/+2Di71G+w2xSmlRNVQyUXwTpEEbxofG80sbfEDVYAsQqKh8mR5UO4D78I= X-Received: by 2002:ac8:5b87:0:b0:2d6:db4d:cb5c with SMTP id a7-20020ac85b87000000b002d6db4dcb5cmr3295453qta.561.1645041374654; Wed, 16 Feb 2022 11:56:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJwzssG3LeEQYChUOZft5C7ACE07elu7OVRX31giBLbQfheFMqXh54O3OcvPt4/JepGSBWxBfQ== X-Received: by 2002:ac8:5b87:0:b0:2d6:db4d:cb5c with SMTP id a7-20020ac85b87000000b002d6db4dcb5cmr3295436qta.561.1645041374249; Wed, 16 Feb 2022 11:56:14 -0800 (PST) Message-ID: <75d1d0f9-950b-6bb1-0ed5-f1d28df0cef8@redhat.com> Date: Wed, 16 Feb 2022 14:56:12 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: musl@lists.openwall.com, Markus Wichmann References: <20220216194020.GA16437@voyager> From: Carlos O'Donell Organization: Red Hat In-Reply-To: <20220216194020.GA16437@voyager> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=carlos@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] Is errno signal-safe? On 2/16/22 14:40, Markus Wichmann wrote: > Hi all, > > today I had a flash of inspiration while staring at some code: errno is > a global variable, right? OK, it is thread-local, but still a global > variable in the context of one thread. And looking at a global variable > while it may (or may not) be modified in a signal handler is not safe to > do. It is required that errno, if changed, must be restored by the signal handler before exit (though note that for glibc the underlying lazy TLS allocation implementation makes errno AS-unsafe for first use in a signal handler because calloc is used to allocate the storage). > So now I have to wonder. There are a bunch of functions that set errno, > that are on the ostensibly async-signal-safe list, like for example > write(). And to my knowledge, changes to errno are not turned back by > sigreturn(). So, are changes to errno made in a signal handler > propagated to the main program? If so, how do I inspect errno correctly > in the main program? I could block signals, but for one thing, doing so > every time errno might be relevant is going to be overkill, and for two, > if the system call I want the errno from is also blocking and I want to > allow signals while the call is blocking, there is no way to do that > without race condition. You don't need to do any of that. A correctly written signal handler must save and restore errno or not modify it all. It has been discussed before by both glibc and musl developers that it might be a good idea all around to wrap signal handlers and save and restore errno in the wrapper to avoid this entire class of problems (but this is easier said than done). > But then again, now that I thought of it, this is so obvious that surely > someone else must have stumbled across it before, right? A solution must > exist, right? It's not entirely obvious (like [1] is not always obvious), but it has been discussed and considered, and the solution is emergent given the standards requirements :} -- Cheers, Carlos. [1] https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=dbb01cbbdb60c34a16d9d48cb58ed3680a5dd36d