From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f54.google.com (mail-oa1-f54.google.com [209.85.160.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D5F523EA8B for ; Tue, 3 Feb 2026 03:23:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770089027; cv=none; b=GMgE+83HRwfJ0CH3LEUBQ1iU33+17mN6MvlbS8bnRC8RnEzDJlb/HeoE/yE0j0NB3YWsCh9XrYzMZpsfjzoAHwAREWtQ+O8AwgDJEZQsw1aDMIqHN5/cc4gXKFFzH1ovYccHoGPO9eAeG869nRh3atI6ruUDR/d0zxazwpUzTMM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770089027; c=relaxed/simple; bh=6ElrO55Og8Plmd9KRwBV3wRAIZ/+Foks3OuMDg0VN+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cH3ePYB3LCT7zYsE5XZDHmZjHAIvKBJROrpKtyqH3wvccpmdTBDf5Q/kG+J1P6/UZFVppCvFJ2CkFNFcQSYJn6+nQM78tpuhdsvoL653v+tZJWiDzgVKrDZehQr+SjkFn4wcqre/wqNmQtffolSpmlo5qZNdEIp1q6W76omfz9k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XNVfBLEi; arc=none smtp.client-ip=209.85.160.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XNVfBLEi" Received: by mail-oa1-f54.google.com with SMTP id 586e51a60fabf-40970f97638so2981328fac.3 for ; Mon, 02 Feb 2026 19:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770089024; x=1770693824; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=yqF7j9+NtH77eRf3A06joazi3wU3U3ry+bHbamRYbTw=; b=XNVfBLEixbkKJIJzIk5pXKUwtULH1mXcq7UnQildgnUNaEyuXH0A7Ok9FkUpoGehFg rZTWGNxNz2QrB92CWDhCnizc9LduwZWpatBr2VnyLQWXcYLriNkqU1UMtwpVe2UZSQFf 0cl5EWo/b4ZlZJME006eHISnbiRZi2LUUWHKS8Ej5Gep6EXT+coFFIkFAU5dTpZhVEch bWblzYDyFj9fpVLcL0FUoeFErJVinWVGzSXeSFhiN0JLTP5D3wt1yTSiqZu27Er9F3il tPlBilaKWToQUH1RA6KGlQnsTVHvzXkJ4YcI6VOhk0ZmifQan+753IilNButHfg7yFvV Gw8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770089024; x=1770693824; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=yqF7j9+NtH77eRf3A06joazi3wU3U3ry+bHbamRYbTw=; b=aJ1eo/Scpp/8fCE8qPgt1nkW9BOKaCztKdZjKmk3BhCvffHk5o3Pj8FTY/LdzndD0Z QmlBCw/mmbcaticIL7RI69PcykUkvz+qaQoPbC0S3sl8+UZfEuppciOh3UpUDu0TPZeP uz6U2yLmXbgESeX+/VScCsiPqu+zM9lk/Qdtd46A9vr728sJD0sf5JQIiGJwitLI96B3 x/CNByRaYT6niwuBH+uNnvNImYpllhE/pdiIKDWdiebAYCg5dOo5QKQCw6t3F1gP2RaN VR5jRKIESxV5rZQeIhjs7M66m2QTzMzetXMus/YeWfnzyo776BlqXZIZhpXMxrNBmqZZ JUqQ== X-Forwarded-Encrypted: i=1; AJvYcCWsf5ghgsikpX4e23c+Rc0gYH7sUx9a1hbVjIs3TI3r4KUpcrp46mb7nVxS/fN5ZgRokoJOvjNYh7KdrKU=@vger.kernel.org X-Gm-Message-State: AOJu0YzQdXaM1mVvI3QHa20w+A3Vag/QmnBtZUMJ1WNequeStPjxBzLv qjdhm2mohInL0o65VsE0TPptI524fasrHSkECxZy+98So8OQYVd+vGfK X-Gm-Gg: AZuq6aKgSTA5Sbaby/P/lOABEBOWSlVBEAQmANUjF5AdJcNgvqrGSbDxN31eZJy0AYk q9k98R7quZWyMjWFOboI8wCIs6DK3L3eLDLI46ot4hIIhTdnaSWRbo6/JID9LO9c+C8R/5/Nw+H DWjta9NNdLn4dTQwt8RjmIWfSepTpBOGxqLdAvZxFZfPZOoh0IUEOBqppswgS0VjgKfEjgrCBp+ 0F6+1mU9UMMuWZJLLaTGReFuI7uI76gZ2vvAgMkWHJTvLgrNCdwdhpwwACfYgfaxAFCKwBvGTVK wcanU78GHLlneByAlI3QX0+G/GEBEw5BOP/cLeITEwFf5hjtijc3fsPunAvwWPj6PzzfewV68q2 qNxqOLX2o1wr1/g40TCcaBZ0bnmkWeY3ducPJtXb5j+ebNKXNK950Y1ycv8nfpFUcaQp6cleFlI zA6CKyS6mD/Q== X-Received: by 2002:a05:6820:1528:b0:662:c161:206e with SMTP id 006d021491bc7-6630f3cdb13mr5166424eaf.82.1770089024432; Mon, 02 Feb 2026 19:23:44 -0800 (PST) Received: from localhost ([2a03:2880:10ff:40::]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-4095717052bsm12915115fac.8.2026.02.02.19.23.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 19:23:43 -0800 (PST) From: Joshua Hahn To: Andrew Morton Cc: David Hildenbrand , Muchun Song , Oscar Salvador , Wupeng Ma , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v2] mm/hugetlb: Restore failed global reservations to subpool Date: Mon, 2 Feb 2026 19:23:40 -0800 Message-ID: <20260203032340.1861093-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260202183918.057dac34b3a1819328814fc9@linux-foundation.org> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Mon, 2 Feb 2026 18:39:18 -0800 Andrew Morton wrote: > On Wed, 21 Jan 2026 09:47:54 -0800 Andrew Morton wrote: > > > On Fri, 16 Jan 2026 15:40:36 -0500 Joshua Hahn wrote: > > > > > Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") > > > fixed an underflow error for hstate->resv_huge_pages caused by > > > incorrectly attributing globally requested pages to the subpool's > > > reservation. > > > > > > Unfortunately, this fix also introduced the opposite problem, which would > > > leave spool->used_hpages elevated if the globally requested pages could > > > not be acquired. This is because while a subpool's reserve pages only > > > accounts for what is requested and allocated from the subpool, its > > > "used" counter keeps track of what is consumed in total, both from the > > > subpool and globally. Thus, we need to adjust spool->used_hpages in the > > > other direction, and make sure that globally requested pages are > > > uncharged from the subpool's used counter. > > > > > > ... > > > > > > Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") > > > Signed-off-by: Joshua Hahn > > > Cc: stable@vger.kernel.org > > > > This (simple, cc:stable) patch presently has no reviews, if someone > > could please be so kind. > > Oh. > > Joshua, it's unclear from the changelog - what are the userspace-visible > effects of the bug? Hello Andrew, Sorry about that, I definitely could have been more explicit with the userspace behavior. What ends up happening is that the subpool will imagine that all of its hugeTLB pages are consumed, so it will be unable to service allocations trying to get hugeTLB pages from it, despite none of the hugeTLB pages in the system really being used. Maybe we can reword the following block: > > > Repeating this process will ultimately render the subpool unable to > > > allocate any hugepages, since it believes that it is using the maximum > > > number of hugepages that the subpool has been allotted. Into this block, to make it more explicit? With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user. Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages. I hope this makes it a bit more clear, and please let me know if there is anything else I can do! I hope you have a great evening, Joshua