From: Szabolcs Nagy <nsz@port70.net>
To: Hydro Flask <hydroflask@yqxmail.com>
Cc: musl@lists.openwall.com, Carlos O'Donell <carlos@redhat.com>,
Florian Weimer <fweimer@redhat.com>
Subject: Re: [musl] Idea: futex() system call entry point
Date: Sat, 18 Jul 2020 09:56:48 +0200 [thread overview]
Message-ID: <20200718075648.GC3210874@port70.net> (raw)
In-Reply-To: <75e93ed84f40957c3750fb42c366447b@yqxmail.com>
* Hydro Flask <hydroflask@yqxmail.com> [2020-07-17 18:21:27 -0700]:
> On 2020-07-17 16:30, Rich Felker wrote:
> > On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote:
> > > Maybe a less complex suggestion is to expose a syscall_cp()
> > > function, so you can get cancellation point functionality for any
> > > system call. I actually quite like that option. How does that sound?
> >
> > In the specific case of futex waits, it's not clear to me that there's
> > any side effect for which you need to know in the cancellation handler
> > whether it occurred, so why can't you just enable async cancel around
> > syscall() and disable it again after?
>
> Oh I hadn't thought of that. That's actually a pretty good short-term
> solution. So you're saying:
>
> int fuxex_wait(int *uaddr, int val, const struct timespec *timeout)
> {
> int old, ret;
>
> /* pthread_setcanceltype() automatically calls
> pthread_testcancel() if async is enabled */
> ret = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS, &old);
> if (ret) {
> errno = ret;
> ret = -1;
> }
> ret = syscall(SYS_futex, uaddr, FUTEX_WAIT, val, timeout);
note that passing libc types (timespec)
to raw syscall is broken (at least on
32bit targets, but in general a libc
type may not match kernel types if this
has to be portable to other libcs).
you have to locally create a type that
is known to match the kernel abi on the
targets you care about and translate
between the libc type and that.
> old = pthread_setcanceltype(old, &old);
> if (old) abort();
> return ret;
> }
>
> I think you're right that even if the futex call succeeds, it's fine to
> cancel since it does not mutate any meaningful observable state. I think
> that should satisfy all my requirements when doing this on musl.
> pthread_testcancel/pthread_setcanceltype should be AS-safe in musl if
> cancellation is disabled or the interrupted code is AC-safe.
>
> That should likely also work in other libcs assuming a sane implementation
> of all the required functions involved. Thank you
>
> Hydro
prev parent reply other threads:[~2020-07-18 7:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 5:51 Hydro Flask
2020-07-17 6:10 ` Florian Weimer
2020-07-17 6:29 ` Hydro Flask
2020-07-17 9:21 ` Szabolcs Nagy
2020-07-17 14:43 ` Carlos O'Donell
2020-07-17 18:57 ` Hydro Flask
2020-07-17 21:10 ` Szabolcs Nagy
2020-07-17 21:19 ` Rich Felker
2020-07-17 21:27 ` Carlos O'Donell
2020-07-17 21:37 ` Hydro Flask
2020-07-17 23:30 ` Rich Felker
2020-07-18 1:21 ` Hydro Flask
2020-07-18 7:56 ` Szabolcs Nagy [this message]
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=20200718075648.GC3210874@port70.net \
--to=nsz@port70.net \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=hydroflask@yqxmail.com \
--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).