[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250905125430.GR1827@brightrain.aerifal.cx>
Date: Fri, 5 Sep 2025 08:54:30 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: ABA problem in aio_suspend()
On Fri, Sep 05, 2025 at 05:35:49AM +0200, Markus Wichmann wrote:
> Am Thu, Sep 04, 2025 at 03:42:20PM -0400 schrieb Rich Felker:
> > We generally don't do generation counters like this that are clearly
> > logically incorrect and just rely on "it's going to wake before
> > something that could plausibly happen happens".
>
> You think oversleeping for *exactly* 2^31 updates is plausible?
>
> > I think the "obvious"
> > way to make it correct is not to allow keeping an existing waiter's
> > tid in the futex, but always putting one's own tid there. However this
> > can create high contention on the futex, perhaps unboundedly so with a
> > lot of threads/cores. That's probably why I tried to just use an
> > existing waiter tid.
> >
>
> This seems like it can create a livelocking situation, where two threads
> calling aio_suspend() keep overwriting the other thread's TID before the
> other thread can go to sleep.
>
> > The obvious way you'd *want* to make it correct is with a condvar, but
> > this can't be done because aio_suspend is required to be AS-safe, and
> > thus cannot use locks, at least not without a lot of care. And it
> > can't do anything like having the waiter join a userspace wait queue,
> > since the AS-safety of aio_suspend means it's legal to longjmp out of
> > it.
> >
>
> And the process-shared code for condvars uses a generation counter. So
> there's another example of it in use.
Oh, I'd completely forgotten it was done/left like that. I think it
was just that, like here, no good solution could be found. This
matches what I said about Linux not offering any good primitives to do
a decent condvar.
In the condvar context it's maybe a little less offensive (counter
space local to the condvar rather than global) and more essential
(being process-shared means there's no way to make the problem go away
even wrapping signals to get AS-safety properties), but essentially
it's the same. So short of a better solution maybe this is what we
should do.
One rather yuck idea that could make it slightly less bad is bounding
the timedwait time to something small and waking to repoll
periodically until the full timeout has expired.
I'm still open to other ideas but for now I'll probably just do as you
suggested and go with a generation counter.
Rich
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.
