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.3 required=5.0 tests=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 18719 invoked from network); 9 Apr 2021 12:16:10 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2021 12:16:10 -0000 Received: (qmail 20041 invoked by uid 550); 9 Apr 2021 12:16:05 -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 20022 invoked from network); 9 Apr 2021 12:16:04 -0000 Date: Fri, 9 Apr 2021 08:15:51 -0400 From: 'Rich Felker' To: Andrey Bugaevskiy Cc: 'Florian Weimer' , musl@lists.openwall.com Message-ID: <20210409121551.GD2546@brightrain.aerifal.cx> References: <00bc01d72c91$bdedb030$39c91090$@yandex-team.ru> <87wntc1zee.fsf@oldenburg.str.redhat.com> <001e01d72c9f$09d1b700$1d752500$@yandex-team.ru> <20210408185511.GC2546@brightrain.aerifal.cx> <00d101d72d39$70639840$512ac8c0$@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d101d72d39$70639840$512ac8c0$@yandex-team.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] errno and swapcontext in a multithreaded setup On Fri, Apr 09, 2021 at 03:11:14PM +0300, Andrey Bugaevskiy wrote: > On Thu, 8 Apr 2021, Rich Felker wrote: > > On Thu, Apr 08, 2021 at 08:46:00PM +0300, Andrey Bugaevskiy wrote: > > > 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. > > > > Perhaps you're confusing the value of errno with its address. No > > function can change the address of errno, only its value. > > Conceptually, __errno_location() is just &errno. > > Well, it's a function returning a value, but I see the point. > I'm still a bit confused about why optimizer can assume that > TLS location never changes though. Because that's a guarantee of the C language. All objects have addresses that are constant for their lifetime. For example, if *you* took &errno or &some_tls_var and saved it, the address you saved is valid until the lifetime of the object ends. It will compare equal to what you get if you take the address again. (The fact tht it doesn't necessarily in your ucontext example is a consequence of you having invoked UB by attempting to "move" an executing block from one thread to another.) Rich