From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f45.google.com (mail-yx1-f45.google.com [74.125.224.45]) (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 477D12D6E66 for ; Thu, 15 Jan 2026 19:45:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768506316; cv=none; b=VHUT//Jb6CWpA1o/P7u4SrclCFbrV1Of5hobIWFYxevE6ofT4AjV9ENCHuHi0H07IYjG1xAmLtn4LMGb5JJjPXpC4cz1G64QT3yQXyxlioOrFHVVPGEUVDryhP4Y94NNNmYlpqes3aoTGu7XUca6mlVaWO14HRQULjSuE+nokDk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768506316; c=relaxed/simple; bh=wK0gwYsd13XO1vi/bU8PqHRYZ8BI0emom8T6gkMMojo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kBR9FKl9koa3Q6LFD+LEP9Qnq35NVzyGGC/OosE8wfPix+zPmX0LwzBhgHBqyv8NqowlrAM+i+dqliNI625sMwMM2Xl5h0gtyLnp+IYsC8MwLS+tsXCfzUfzlE9uqLsFsVInBX31VgClhqVIOMufqWMALjJj1YSIc627NUh65Kg= 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=T4N31qj9; arc=none smtp.client-ip=74.125.224.45 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="T4N31qj9" Received: by mail-yx1-f45.google.com with SMTP id 956f58d0204a3-64471fcdef0so1108695d50.1 for ; Thu, 15 Jan 2026 11:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768506313; x=1769111113; 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=P7GsFDW3HeDyKihzotR4/NfBM14wwU30+97RfyEF1UY=; b=T4N31qj9tUsMaWJrS7LyUf6JFhaHgUoYPu+VabEHtqRnV3DDqKMEXYVqmYeLQ209dA Y/nHWTKoGS+r3wRdubnaff6sgl8ebJ4FlY7Pb2R2TR8rPAotykHHfWM6yTRAjrTKU6Bn b6uNenk3F7vfnffJfOsdTTnc5w4EBScmxPuHiwJPYxsp/bTqITNLl+Mmcq2UcXsz3HVn D8s23XGa/TFuC0f03jdHVseGsh9yDbHoq0vDRNi0Gd5hPbG8oZ+JwHG3lbNXMrupbKHn hpv7lCTrik/0I9ucC7f18coqeKiOjbLxmQfXmyRP85BTS0g3/EBsEFxAi0OlvPzZNh8x JIwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768506313; x=1769111113; 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=P7GsFDW3HeDyKihzotR4/NfBM14wwU30+97RfyEF1UY=; b=S18v08xmChvzqeC6+kYHubCab91szgVOZGX82Mo/BBnFAuxa3jG6aMEF0F+O84HtMA /dVJNWSFKmOxn6waVRqTmfdgFT2FrE29i8nn765USUo4WI78Rp1ryz3pzTh6Mxynn2km b4f2jhtsuZ3fo/H4ofXkDPLV1NZUVAbNIjMl/ARmOmjtM9PdvhsfhbjMX4gGY+IdJJsD BjNFGo00C5sBTJICzwQCMdKBy8syIM/cSZV/E5TTLUCJe+nrREuKCeSzpVB2t0U0EG/l wJGIowVt48tkn1QJLm37NdTEUjme0UCS06SXppGP8GgVF+5c+B11UQboGLG8XETrtFB0 kdUA== X-Forwarded-Encrypted: i=1; AJvYcCWKa8FB6KjUyqCH7UgTY9sd18p4HIqcYdNYUSviIqZGPJMi61kj801v9Hyr5s/sIBzf4dSHK3eYNW4BF5Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yzy/GaRefa0B7BajEGlG9Z5ykxH2YGQbS/GQdTG/t+OYN5KYHRA efU6z+TU6fs7XD43QxcOJ0erUXqzfpEMp1hHOnYbuQ6SNzQI2MAR/hAaQkVRBg== X-Gm-Gg: AY/fxX6e642plF1eOnz5mq+aHKshnVPEC8R5HD6r0cpUWINicfWYgl0dQcZ0KGf3T4r iv51s1c4hJO2OPlviCwgICv0lISGMdJhsUXVWFkmO0Ic6xZXiTUw2sX/GkPGwg5KNCfbxqKD5zR xIlfHZZzlgaW09/878eluRxGe9fHtevlvIdF5SyNqT6cl1QFrnlU+D/Rdnd+WSJ//hiHtH2nRgx aNmEjFyQvz6kChDiFbdmHkt+8nl7K9jwbJBF/x4+jciH1bgqpz+eyzTc1nt4t1PRaCxPXe5TYjI w37Q4zZa06i12IUmnQJQQLJlakqqL+UZwzCRp6tuSkcnRDsndn3vGW+p2GoMJdbYwCxxewcSdMp 1k1gPYvzeGujqUAfhv/LRWUYCUtQLhu/w0j1A5+q4VfQzipIDdcE8C6A3TMkHUJ//kF4Fnszo43 ydhesthXmOrw== X-Received: by 2002:a05:690c:7288:b0:78f:b163:782 with SMTP id 00721157ae682-793c53eadd1mr14217807b3.58.1768506313106; Thu, 15 Jan 2026 11:45:13 -0800 (PST) Received: from localhost ([2a03:2880:25ff:56::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-64916ffb951sm205444d50.2.2026.01.15.11.45.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 11:45:12 -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, kernel-team@meta.com, stable@vger.kernel.org Subject: Re: [PATCH 1/3] mm/hugetlb: Restore failed global reservations to subpool Date: Thu, 15 Jan 2026 14:45:10 -0500 Message-ID: <20260115194511.836766-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260115111946.4b50c5dbe6c6bd01638e4b16@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 Thu, 15 Jan 2026 11:19:46 -0800 Andrew Morton wrote: > On Thu, 15 Jan 2026 13:14:35 -0500 Joshua Hahn wrote: Hello Andrew, I hope you are doing well. Thank you for your help as always! > > 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. > > > > Each failed allocation attempt increments the used_hpages counter by > > how many pages were requested from the global pool. Ultimately, this > > renders the subpool unusable, as used_hpages approaches the max limit. > > > > The issue can be reproduced as follows: > > 1. Allocate 4 hugetlb pages > > 2. Create a hugetlb mount with max=4, min=2 > > 3. Consume 2 pages globally > > 4. Request 3 pages from the subpool (2 from subpool + 1 from global) > > 4.1 hugepage_subpool_get_pages(spool, 3) succeeds. > > used_hpages += 3 > > 4.2 hugetlb_acct_memory(h, 1) fails: no global pages left > > used_hpages -= 2 > > 5. Subpool now has used_hpages = 1, despite not being able to > > successfully allocate any hugepages. It believes it can now only > > allocate 3 more hugepages, not 4. > > > > 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. > > > > The underflow issue that commit a833a693a490 fixes still remains fixed > > as well. > > Thanks, I submitted the above to the Changelog Of The Year judging > committee. : -) Thank you for the kind words! > > Fixes: a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") > > Signed-off-by: Joshua Hahn > > Cc: stable@vger.kernel.org > > I'll add this to mm.git's mm-hotfixes queue, for testing and review > input. Sounds good to me! I'll wait a bit in case others have different concerns, but I'll send out a new version which addresses your comments below (and any future comments) in a day or two. > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > > @@ -6560,6 +6560,7 @@ long hugetlb_reserve_pages(struct inode *inode, > > struct resv_map *resv_map; > > struct hugetlb_cgroup *h_cg = NULL; > > long gbl_reserve, regions_needed = 0; > > + unsigned long flags; > > This could have been local to the {block} which uses it, which would be > nicer, no? Definiely, I'll address this in v2! > > int err; > > > > /* This should never happen */ > > @@ -6704,6 +6705,13 @@ long hugetlb_reserve_pages(struct inode *inode, > > */ > > hugetlb_acct_memory(h, -gbl_resv); > > } > > + /* Restore used_hpages for pages that failed global reservation */ > > + if (gbl_reserve && spool) { > > + spin_lock_irqsave(&spool->lock, flags); > > + if (spool->max_hpages != -1) > > + spool->used_hpages -= gbl_reserve; > > + unlock_or_release_subpool(spool, flags); > > + } > > I'll add [2/3] and [3/3] to the mm-new queue while discarding your > perfectly good [0/N] :( > > Please, let's try not to mix backportable patches with the > non-backportable ones? Oh no! Sorry, this is my first time Cc-ing stable so I wasn't aware of the implications. In v2, I'll send the two out as separate patches, so that it's easier to backport. I was just eager to send out 2/3 and 3/3 because I've been waiting for a functional hugetlb patch to smoosh these cleanups into. I'll be more mindful in the future. Thank you again, I hope you have a great day!! Joshua