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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 27636 invoked from network); 8 Apr 2021 18:29:56 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 8 Apr 2021 18:29:56 -0000
Received: (qmail 29901 invoked by uid 550); 8 Apr 2021 18:29:54 -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 32400 invoked from network); 8 Apr 2021 17:46:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default;
	t=1617903960; bh=lIc+CVcTUcG90MVMltkQb2G47NLN+2pDPrHO9LQab4c=;
	h=Message-ID:References:Date:Subject:To:From:In-Reply-To:Cc;
	b=dcnEcDhSTrGXx+f61+ka3DyABOgLBUgOvZNehTLidjMs7XCZ+DF4Z1dGJg3jLDaE8
	 a1QZBGlZX8bL4sJ8lwrPp6vhu+Sox5l9SkJbA9UaOqIeqyzN4tqd0sZFUfiz5pspBp
	 wI2a6ljL4gOPXrF6EECA3kgBMPYbHjoejxHLMyuc=
Authentication-Results: iva8-d077482f1536.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru
From: "Andrey Bugaevskiy" <bugaevskiy@yandex-team.ru>
To: "'Florian Weimer'" <fweimer@redhat.com>
Cc: <musl@lists.openwall.com>
References: <00bc01d72c91$bdedb030$39c91090$@yandex-team.ru> <87wntc1zee.fsf@oldenburg.str.redhat.com>
In-Reply-To: <87wntc1zee.fsf@oldenburg.str.redhat.com>
Date: Thu, 8 Apr 2021 20:46:00 +0300
Message-ID: <001e01d72c9f$09d1b700$1d752500$@yandex-team.ru>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFhj4vmgm0to5vZEvd03mIy9uPHmQMDxG0Xq34At5A=
Content-Language: ru
Subject: RE: [musl] errno and swapcontext in a multithreaded setup

On Thu, 8 Apr 2021, Florian Weimer wrote:
> * Andrey Bugaevskiy:
> 
> > I'm using makecontext/swapcontext to migrate contexts between threads
> > and this sometimes leads to getting incorrect errno values.
> >
> > Investigating further I've noticed that __errno_location
> > is marked __attribute__((const)).
> > This causes optimizers to assume that errno address never changes
> > in the scope of the function which is not the case in my scenario.
> 
> The optimizers make the same assumption for actual thread-local
> variables, not just __errno_location.  Migrating contexts between
> threads results in undefined behavior.

Can you please point me to some explanation why this optimization
is valid for thread-local variables?

As far as I can imagine optimizer should at least prove that it
won't be changed from some other place or (if the variable is local
to the function) that it is not changed by a recursive call.

I believe the only reason optimizer is allowed to remove the call
to __errno_location is the "const" attribute.

--
Andrey Bugaevskiy