From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95FFF384250 for ; Mon, 20 Jul 2026 23:27:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784590043; cv=none; b=Y/N88HcPGy1mbv/ralZZelE/hNiEF45/98WPtP3KwkE5r7x5eQVmRfZI0IuZd8sMsEw8IOl2Eb47EGhGQkLrU8R6cJ2hnxSV6VHCoKH7qtMSKi6xoXqt+dKM7C63xAg4nV4/ebYxqBp7l/Ti9+dn9plzUuHqNHNW5ck2IZiQl+o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784590043; c=relaxed/simple; bh=utsyQNooravNV4x6Fb8hHQNDh5JCUZEhpQzk23/eugI=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Hevb0TVXHvuoX801ZQ60yNrnoy1h46wv8KvRmuJ1a7oYfCiZtgahVYoWnzfqpwSpLQCeGJURXEFOZBbYi4BnVIwRw9DO2HMYq1YQ7o1GWBaShf1gUA2FfVgPLsAgUqwmjhfogXGNDxykoOjq3ZCMXnyxo1EweG0UvDLvkpKqGEI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=qrCaLyuh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="qrCaLyuh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F0AD1F000E9; Mon, 20 Jul 2026 23:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1784590042; bh=q0tMGbUKVmQ24ICOTjdeUvzTZMPaNn3f8k1KcJxmgMY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=qrCaLyuhWboXRKi0PgpTk6wTfiYmLQFUJV+K9TXPH09nAOEC2xvNOLFHQNjRHx+fO X2/Sac+5rH4Ig2J9UI4EbvxFk2mM3jLekz4VEbcOy25cKFwzx7tKO+gEpGGMmFnJhH b447HY0SqRPbDbX23HF8BP1woOZt8DEL+dAAuLFw= Date: Mon, 20 Jul 2026 16:27:21 -0700 From: Andrew Morton To: Joshua Hahn Cc: Yichong Chen , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Barry , David Gibson , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] hugetlb: fix subpool release race Message-Id: <20260720162721.fd07cbcb5625c7ad38725a36@linux-foundation.org> In-Reply-To: <20260720143130.516711-1-joshua.hahnjy@gmail.com> References: <20260720085024.1392261-1-chenyichong@uniontech.com> <20260720143130.516711-1-joshua.hahnjy@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 20 Jul 2026 07:31:29 -0700 Joshua Hahn 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 Thanks. Yichong, can you please consider Joshua's observations and perhaps resend with a more accurate changelog?