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

[Sebastian Andrzej Siewior]

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.

> ---
>  kernel/fork.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 416758c8a3d4..bc32ea19099e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1996,9 +1996,9 @@ static bool need_futex_hash_allocate_default(u64 clone_flags)
>  {
>  	/*
>  	 * Allocate a default futex hash for any sibling that will
> -	 * share the parent's mm, except vfork.
> +	 * share the parent's mm.
>  	 */
> -	return (clone_flags & (CLONE_VM | CLONE_VFORK)) == CLONE_VM;
> +	return clone_flags & CLONE_VM;
>  }
>  
>  /*

Sebastian