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,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 22429 invoked from network); 16 Feb 2022 21:01:34 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 16 Feb 2022 21:01:34 -0000
Received: (qmail 3948 invoked by uid 550); 16 Feb 2022 21:01:31 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 3903 invoked from network); 16 Feb 2022 21:01:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1645045279;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=H3/t+RUSSzaJUg8AGjAx9wtsk1LPgQkQ7mGZWrVV4JU=;
	b=GF58RTomUiw33Q39hPQFFUqYSQlGz7pl0VCOM/pkCDhYWduE2YEgpQhmvOvxt3eedxXJy1
	xJkFr7eC5DfOflJTG5D4cxXG0hjDn8Tr0BwiO4LtRuoPXzt11TtVJO/1vLXSupEW1pbKis
	GN52MijaoqMWUOnjw9ZIn10QkoOOB8M=
X-MC-Unique: 0Qcsvj7dMTS_lDt68MTL-A-1
From: Florian Weimer <fweimer@redhat.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: musl@lists.openwall.com,  Markus Wichmann <nullplan@gmx.net>
References: <20220216194020.GA16437@voyager>
	<75d1d0f9-950b-6bb1-0ed5-f1d28df0cef8@redhat.com>
Date: Wed, 16 Feb 2022 22:01:13 +0100
In-Reply-To: <75d1d0f9-950b-6bb1-0ed5-f1d28df0cef8@redhat.com> (Carlos
	O'Donell's message of "Wed, 16 Feb 2022 14:56:12 -0500")
Message-ID: <87wnhuy19i.fsf@oldenburg.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Subject: Re: [musl] Is errno signal-safe?

* Carlos O'Donell:

> 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).

glibc uses initial-exec TLS under the hood for storing the int variable,
so the variable access itself async-signal-safe (whether it goes
directly to errno@GLIBC_PRIVATE or via __errno_location, it doesn't
matter).

Thanks,
Florian