Re: [PATCH] hugetlb: fix subpool release race

From: Andrew Morton

Date: Mon Jul 20 2026 - 19:27:28 EST


On Mon, 20 Jul 2026 07:31:29 -0700 Joshua Hahn <joshua.hahnjy@xxxxxxxxx> 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@xxxxxxxxx>

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