Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 18 Jul 2020 09:56:48 +0200
From: Szabolcs Nagy <>
To: Hydro Flask <>
Cc:, Carlos O'Donell <>,
	Florian Weimer <>
Subject: Re: Idea: futex() system call entry point

* Hydro Flask <> [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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.