From: Ariadne Conill <ariadne@dereferenced.org>
To: musl@lists.openwall.com
Subject: Re: [musl] errno and swapcontext in a multithreaded setup
Date: Thu, 8 Apr 2021 11:40:43 -0600 (MDT) [thread overview]
Message-ID: <f71219a-5b24-1e6b-c9e7-1d4428df33b9@dereferenced.org> (raw)
In-Reply-To: <00bc01d72c91$bdedb030$39c91090$@yandex-team.ru>
Hello,
On Thu, 8 Apr 2021, Andrey Bugaevskiy wrote:
> Hi,
>
> I'm using makecontext/swapcontext to migrate contexts between threads
> and this sometimes leads to getting incorrect errno values.
This is not supported by libucontext.
> 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.
>
> Namely, this code:
>
> int test(ucontext_t* old_ctx, const ucontext_t* new_ctx) {
> int err_before = errno;
> swapcontext(old_ctx, new_ctx);
> int err_after = errno;
> return err_before | err_after; // do not optimize out
> }
>
> translates with -O1 to something like this:
>
> 0000000000001109 <test>:
> 1109: endbr64
> 110d: push %r13
> 110f: push %r12
> 1111: push %rbp
> 1112: push %rbx
> 1113: sub $0x8,%rsp
> 1117: mov %rdi,%r12
> 111a: mov %rsi,%r13
> 111d: callq 1030 <__errno_location@plt>
> 1122: mov %rax,%rbx
> 1125: mov (%rax),%ebp
> 1127: mov %r13,%rsi
> 112a: mov %r12,%rdi
> 112d: callq 1020 <swapcontext@plt>
> 1132: mov %ebp,%eax
> 1134: or (%rbx),%eax
> 1136: add $0x8,%rsp
> 113a: pop %rbx
> 113b: pop %rbp
> 113c: pop %r12
> 113e: pop %r13
> 1140: retq
>
> errno location is being stored to a register and then reused.
> However a call to __errno_location after swapcontext is expected to
> return a different address if the context have been swapped back
> into another thread.
> There are a couple of similarly affected functions (pthread_self,
> __h_errno_location).
>
> Removing __attribute__((const)) or changing it
> to __attribute__((pure)) resolves the problem in newly compiled code.
I believe these values use TLS (but not 100% sure, at least in uClibc
they do). libucontext is not aware of TLS, and so clobbers the TLS
register. You could modify libucontext to add awareness of the TLS
register, but I don't think we would accept a patch for that.
> Can this change be considered for the future versions of musl?
No, musl is working as designed here.
Ariadne
next prev parent reply other threads:[~2021-04-08 17:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 16:10 Andrey Bugaevskiy
2021-04-08 17:04 ` Florian Weimer
2021-04-08 17:17 ` Rich Felker
2021-04-08 17:46 ` Andrey Bugaevskiy
2021-04-08 18:55 ` Rich Felker
2021-04-09 12:11 ` Andrey Bugaevskiy
2021-04-09 12:15 ` 'Rich Felker'
2021-04-08 17:40 ` Ariadne Conill [this message]
2021-04-08 17:49 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f71219a-5b24-1e6b-c9e7-1d4428df33b9@dereferenced.org \
--to=ariadne@dereferenced.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).