From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 AFAB0190664; Sun, 1 Mar 2026 02:01:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772330480; cv=none; b=uXSNRioWT1wwX3T7XjXrQ9rvSt8lbKwp16jknb89cbuju0P+SfDicBVQpuJUxdAtmiGZUpu1ayaSoE2ch9yE/jGglk6irgyLm3CGdvNuq5Ho9lbXH9FmYoectyKu4HWtnGWeyrKYD7CbEUIiG5Nvz/IqjtSAqC9tbOHlKIjgonM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772330480; c=relaxed/simple; bh=hZkPE5CNYOyIS3Bm8o17c+JUNwunD0H7xdisOEU6l3g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Rv98JQxjAbgCGdrfRK9emiQqEu4utJ1MH12dISyvjstjeIiDXpV5tZ4Eswgclrb+NjWJQ+Bxj2O9kamaBXulkekbIH9fXYN+eHw56RGzKmQez41gPvtUt+CsfUs9yIrCwes5HE7G/tcAqG8gqyHPM9KRvxDlgqsnxzw4cj/ep8s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qXnp+zrl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qXnp+zrl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C454C19424; Sun, 1 Mar 2026 02:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772330480; bh=hZkPE5CNYOyIS3Bm8o17c+JUNwunD0H7xdisOEU6l3g=; h=From:To:Cc:Subject:Date:From; b=qXnp+zrl4QCHXk1Fb81p5jf+RilL3eQT7ozDs5GdG1kJSqJxhLkRNkHMkzpDnsBh/ o5C7dsjp1xyB78YxCKqKlzbiz3QOdRTSgru1qP2aJlD1Wmy3+lXYhPt62MGrxZzpe9 /avbdgJ8Tb+b9lRpFutiz2KjW+ke5PIXrzijVi1i5dcZYykM9hivuPOGEQXrTbqxmY vm1vx6flQg57Gkz3Z7SYjTIh0X+5vQiKGznMOazSBGvH58/sKlcD/LPJXlvyQSIc+5 JCt6XvUlM6TsY1+2TWa6uor78xq89HZxYs8C8www3RN55fKeN5645k/pcq03HEt6VI 7eVUBNI01NArA== From: Sasha Levin To: stable@vger.kernel.org, liwang@redhat.com Cc: "David Hildenbrand (Red Hat)" , Waiman Long , Mark Brown , Shuah Khan , Andrew Morton , linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: FAILED: Patch "selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs" failed to apply to 5.10-stable tree Date: Sat, 28 Feb 2026 21:01:17 -0500 Message-ID: <20260301020118.1728520-1-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Hint: ignore X-stable: review Content-Transfer-Encoding: 8bit The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From 1aa1dd9cc595917882fb6db67725442956f79607 Mon Sep 17 00:00:00 2001 From: Li Wang Date: Sun, 21 Dec 2025 20:26:38 +0800 Subject: [PATCH] selftests/mm/charge_reserved_hugetlb: drop mount size for hugetlbfs charge_reserved_hugetlb.sh mounts a hugetlbfs instance at /mnt/huge with a fixed size of 256M. On systems with large base hugepages (e.g. 512MB), this is smaller than a single hugepage, so the hugetlbfs mount ends up with zero capacity (often visible as size=0 in mount output). As a result, write_to_hugetlbfs fails with ENOMEM and the test can hang waiting for progress. === Error log === # uname -r 6.12.0-xxx.el10.aarch64+64k #./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages = 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # write_to_hugetlbfs: Error mapping the file: Cannot allocate memory # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ... # mount |grep /mnt/huge none on /mnt/huge type hugetlbfs (rw,relatime,seclabel,pagesize=512M,size=0) # grep -i huge /proc/meminfo ... HugePages_Total: 10 HugePages_Free: 10 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 524288 kB Hugetlb: 5242880 kB Drop the mount args with 'size=256M', so the filesystem capacity is sufficient regardless of HugeTLB page size. Link: https://lkml.kernel.org/r/20251221122639.3168038-3-liwang@redhat.com Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests") Signed-off-by: Li Wang Acked-by: David Hildenbrand (Red Hat) Acked-by: Waiman Long Cc: Mark Brown Cc: Shuah Khan Cc: Signed-off-by: Andrew Morton --- tools/testing/selftests/mm/charge_reserved_hugetlb.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh index e1fe16bcbbe88..fa6713892d82d 100755 --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -290,7 +290,7 @@ function run_test() { setup_cgroup "hugetlb_cgroup_test" "$cgroup_limit" "$reservation_limit" mkdir -p /mnt/huge - mount -t hugetlbfs -o pagesize=${MB}M,size=256M none /mnt/huge + mount -t hugetlbfs -o pagesize=${MB}M none /mnt/huge write_hugetlbfs_and_get_usage "hugetlb_cgroup_test" "$size" "$populate" \ "$write" "/mnt/huge/test" "$method" "$private" "$expect_failure" \ @@ -344,7 +344,7 @@ function run_multiple_cgroup_test() { setup_cgroup "hugetlb_cgroup_test2" "$cgroup_limit2" "$reservation_limit2" mkdir -p /mnt/huge - mount -t hugetlbfs -o pagesize=${MB}M,size=256M none /mnt/huge + mount -t hugetlbfs -o pagesize=${MB}M none /mnt/huge write_hugetlbfs_and_get_usage "hugetlb_cgroup_test1" "$size1" \ "$populate1" "$write1" "/mnt/huge/test1" "$method" "$private" \ -- 2.51.0