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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Sep 15, 2026 at 01:06:19PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-09-11 11:04:47 [+0200], Peter Zijlstra wrote:
> > So I can confirm that the below does in fact cure your testcase.
> > 
> > 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?
> 
> in v2 I moved everything struct signal because the private hash should
> live there as per review. This explains the original check in
> need_futex_hash_allocate_default(). In v3 I moved to mm while the check
> remained unchanged.
> 
> The mm is cloned on CLONE_VM. Kernel threads don't get a private hash
> due to mm == NULL check in futex_hash_allocate_default() which was added
> in v4 with auto-resize.
> 
> To get the whole magic to work, we need to create the private hash once
> the first "parallel" user is created, the first thread.
> Skipping it for CLONE_VFORK violates this. I don't see why we shouldn't
> do what you just suggested.

Thanks, I'll go write up a Changelog or something and stick it in
locking/urgent.