Re: [BUG] futex: scheduling-while-atomic because nested vfork can break guard(private_hash)
From: Jann Horn
Date: Fri Sep 11 2026 - 11:48:58 EST
On Fri, Sep 11, 2026 at 1:51 PM Thomas Gleixner <tglx@xxxxxxxxxx> 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()?