Re: [BUG] futex: scheduling-while-atomic because nested vfork can break guard(private_hash)

[Davidlohr Bueso <dave@stgolabs.net>]

On Fri, 11 Sep 2026, Jann Horn wrote:

>On Fri, Sep 11, 2026 at 1:51???PM Thomas Gleixner <tglx@kernel.org> wrote:
>> On Fri, Sep 11 2026 at 11:04, Peter Zijlstra wrote:
>> > Per commit: ee9dce44362b ("futex: Drop CLONE_THREAD requirement for private default hash alloc")
>> > the reason for excluding vfork() was performance and thinking this
>> > would/could not matter, which you've proven to be clearly false.
>> >
>> > Thomas?
>>
>> I don't remember why we excluded VFORK in the first place. Sebastian?
>
>That was introduced in commit ee9dce44362b ("futex: Drop CLONE_THREAD
>requirement for private default hash alloc"), and the commit message
>says:
>
>| Loosen the check to cover any CLONE_VM clone, except vfork().  Excluding
>| vfork keeps the existing paths untouched (no overhead), and we can't
>| race in the first place: either the parent is suspended and the child
>| runs alone, or mm->futex_ref is already allocated from an earlier
>| CLONE_VM.
>
>So I think that was purely supposed to be a performance optimization
>for single-threaded processes that do vfork()+exec()?

Right, but didn't really measure anything and am certainly fine with
Peter's fixlet. Sorry for breaking things.

Thanks,
Davidlohr