Re: [PATCH] hugetlb: fix subpool release race

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 20 Jul 2026 07:31:29 -0700 Joshua Hahn <joshua.hahnjy@gmail.com> wrote:

> Hello Yichong, thank you for the patch!
> 
> > unlock_or_release_subpool() drops spool->lock before checking whether the
> > subpool can be freed.  However, subpool_is_free() reads fields that are
> > updated under spool->lock, including count, used_hpages and rsv_hpages.
> > 
> > Another thread can update those fields before the first thread evaluates
> > subpool_is_free(), allowing both threads to observe the final freeable
> > state and release the subpool.
> 
> I don't think that the race you are mentioning can be hit in practice (i.e.
> there is no user-visible change for this) since two threads cannot actually
> observe the freeable state at the same time.
> 
> subpool_is_free() does an early exit on spool->count so it will never reach
> the inside if block and have two threads try to decrement the
> spool->hstate and free the spool twice. I'm wondering if we need the Fixes
> tag in this case.
> 
> I do think that this is not obvious though, so having the subpool_is_free
> check inside the locked section makes sense to me too.
> 
> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com>

Thanks.  Yichong, can you please consider Joshua's observations and
perhaps resend with a more accurate changelog?