write_to_hugetlbfs currently parses the -s size argument with atoi() into an int. This silently accepts malformed input, cannot report overflow, and can truncate large sizes.

--- Error log --- # uname -r 6.12.0-xxx.el10.aarch64+64k

# ls /sys/kernel/mm/hugepages/hugepages-* hugepages-16777216kB/ hugepages-2048kB/ hugepages-524288kB/

#./charge_reserved_hugetlb.sh -cgroup-v2 # ----------------------------------------- ... # nr hugepages = 10 # writing cgroup limit: 5368709120 # writing reseravation limit: 5368709120 ... # Writing to this path: /mnt/huge/test # Writing this size: -1610612736 <--------

Switch the size variable to size_t and parse -s with sscanf("%zu", ...). Also print the size using %zu.

This avoids incorrect behavior with large -s values and makes the utility more robust.

Signed-off-by: Li Wang liwang@redhat.com Cc: David Hildenbrand david@kernel.org Cc: Mark Brown broonie@kernel.org Cc: Shuah Khan shuah@kernel.org Cc: Waiman Long longman@redhat.com --- tools/testing/selftests/mm/write_to_hugetlbfs.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/mm/write_to_hugetlbfs.c b/tools/testing/selftests/mm/write_to_hugetlbfs.c index 34c91f7e6128..ecb5f7619960 100644 --- a/tools/testing/selftests/mm/write_to_hugetlbfs.c +++ b/tools/testing/selftests/mm/write_to_hugetlbfs.c @@ -68,7 +68,7 @@ int main(int argc, char **argv) int key = 0; int *ptr = NULL; int c = 0; - int size = 0; + size_t size = 0; char path[256] = ""; enum method method = MAX_METHOD; int want_sleep = 0, private = 0; @@ -86,7 +86,10 @@ int main(int argc, char **argv) while ((c = getopt(argc, argv, "s:p:m:owlrn")) != -1) { switch (c) { case 's': - size = atoi(optarg); + if (sscanf(optarg, "%zu", &size) != 1) { + perror("Invalid -s."); + exit_usage(); + } break; case 'p': strncpy(path, optarg, sizeof(path) - 1); @@ -131,7 +134,7 @@ int main(int argc, char **argv) }

if (size != 0) { - printf("Writing this size: %d\n", size); + printf("Writing this size: %zu\n", size); } else { errno = EINVAL; perror("size not found");

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 effectively 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

Mount hugetlbfs with size=${size}, the number of bytes the test will reserve/write, so the filesystem capacity is sufficient regardless of HugeTLB page size.

Signed-off-by: Li Wang liwang@redhat.com Cc: David Hildenbrand david@kernel.org Cc: Mark Brown broonie@kernel.org Cc: Shuah Khan shuah@kernel.org Cc: Waiman Long longman@redhat.com --- 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 249a5776c074..ac2744dbc0bd 100755 --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -295,7 +295,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,size=${size} none /mnt/huge

write_hugetlbfs_and_get_usage "hugetlb_cgroup_test" "$size" "$populate" \ "$write" "/mnt/huge/test" "$method" "$private" "$expect_failure" \ @@ -349,7 +349,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,size=${size} none /mnt/huge

write_hugetlbfs_and_get_usage "hugetlb_cgroup_test1" "$size1" \ "$populate1" "$write1" "/mnt/huge/test1" "$method" "$private" \

On 12/21/25 09:58, Li Wang wrote:

The hugetlb cgroup usage wait loops in charge_reserved_hugetlb.sh were unbounded and could hang forever if the expected cgroup file value never appears (e.g. due to bugs, timing issues, or unexpected behavior).

Did you actually hit that in practice? Just wondering.

--- Error log --- # uname -r 6.12.0-xxx.el10.aarch64+64k

# ls /sys/kernel/mm/hugepages/hugepages-* hugepages-16777216kB/ hugepages-2048kB/ hugepages-524288kB/

#./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 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ...

Introduce a small helper, wait_for_file_value(), and use it for:

• waiting for reservation usage to drop to 0,
• waiting for reservation usage to reach a given size,
• waiting for fault usage to reach a given size.

This makes the waits consistent and adds a hard timeout (120 tries with 0.5s sleep) so the test fails instead of stalling indefinitely.

Signed-off-by: Li Wang liwang@redhat.com Cc: David Hildenbrand david@kernel.org Cc: Mark Brown broonie@kernel.org Cc: Shuah Khan shuah@kernel.org Cc: Waiman Long longman@redhat.com

---

.../selftests/mm/charge_reserved_hugetlb.sh | 47 ++++++++++--------- 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh index e1fe16bcbbe8..249a5776c074 100755 --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -100,7 +100,7 @@ function setup_cgroup() { echo writing cgroup limit: "$cgroup_limit" echo "$cgroup_limit" >$cgroup_path/$name/hugetlb.${MB}MB.$fault_limit_file

• echo writing reseravation limit: "$reservation_limit"

• echo writing reservation limit: "$reservation_limit" echo "$reservation_limit" > \ $cgroup_path/$name/hugetlb.${MB}MB.$reservation_limit_file

@@ -112,41 +112,46 @@ function setup_cgroup() { fi } +function wait_for_file_value() {

• local path="$1"
• local expect="$2"
• local max_tries="120"
• local i cur

I would just move "cur" into the loop; I don't see a reason to print it on the error path when you printed the value on the last "Waiting" line?

local cur="$(cat "$path")"

Also, not sure if you really need the "local i" here.

What if the path does not exist, do we want to catch that earlier and bail out instead of letting "cat" fail here?

• for ((i=1; i<=max_tries; i++)); do
• cur="$(cat "$path")"
• if [[ "$cur" == "$expect" ]]; then

•  return 0
  

• fi
• echo "Waiting for $path to become '$expect' (current: '$cur') (try $i/$max_tries)"
• sleep 0.5

Any reason we don't go for the more intuitive "wait 1s" - max 60s wait?

• done

Nothing else jumped at me.

David Hildenbrand (Red Hat) david@kernel.org wrote:

On 12/21/25 09:58, Li Wang wrote:

...

The hugetlb cgroup usage wait loops in charge_reserved_hugetlb.sh were unbounded and could hang forever if the expected cgroup file value never appears (e.g. due to bugs, timing issues, or unexpected behavior).

Did you actually hit that in practice? Just wondering.

Yes.

On an aarch64 64k setup with 512MB hugepages, the test failed earlier (hugetlbfs got mounted with an effective size of 0 due to size=256M), so write_to_hugetlbfs couldn’t allocate the expected pages. After that, the script’s wait loops never observed the target value, so they spun forever.

Detail see below logs.

...

--- Error log --- # uname -r 6.12.0-xxx.el10.aarch64+64k

# ls /sys/kernel/mm/hugepages/hugepages-* hugepages-16777216kB/ hugepages-2048kB/ hugepages-524288kB/

#./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 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 # Waiting for hugetlb memory reservation to reach size 2684354560. # 0 ...

Introduce a small helper, wait_for_file_value(), and use it for:

• waiting for reservation usage to drop to 0,
• waiting for reservation usage to reach a given size,
• waiting for fault usage to reach a given size.

This makes the waits consistent and adds a hard timeout (120 tries with 0.5s sleep) so the test fails instead of stalling indefinitely.

Signed-off-by: Li Wang liwang@redhat.com Cc: David Hildenbrand david@kernel.org Cc: Mark Brown broonie@kernel.org Cc: Shuah Khan shuah@kernel.org Cc: Waiman Long longman@redhat.com

---

.../selftests/mm/charge_reserved_hugetlb.sh | 47 ++++++++++--------- 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh index e1fe16bcbbe8..249a5776c074 100755 --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh @@ -100,7 +100,7 @@ function setup_cgroup() { echo writing cgroup limit: "$cgroup_limit" echo "$cgroup_limit" >$cgroup_path/$name/hugetlb.${MB}MB.$fault_limit_file

• echo writing reseravation limit: "$reservation_limit"

• echo writing reservation limit: "$reservation_limit" echo "$reservation_limit" > \ $cgroup_path/$name/hugetlb.${MB}MB.$reservation_limit_file

@@ -112,41 +112,46 @@ function setup_cgroup() { fi }

+function wait_for_file_value() {

• local path="$1"
• local expect="$2"
• local max_tries="120"
• local i cur

I would just move "cur" into the loop; I don't see a reason to print it on the error path when you printed the value on the last "Waiting" line?

    local cur="$(cat "$path")"

+1

Also, not sure if you really need the "local i" here.

What if the path does not exist, do we want to catch that earlier and bail out instead of letting "cat" fail here?

Yes, we can add a file check before the "cat" loop.

...

• for ((i=1; i<=max_tries; i++)); do
• cur="$(cat "$path")"
• if [[ "$cur" == "$expect" ]]; then

•  return 0
  

• fi
• echo "Waiting for $path to become '$expect' (current: '$cur') (try $i/$max_tries)"
• sleep 0.5

Any reason we don't go for the more intuitive "wait 1s" - max 60s wait?

Sure, the total loop time are same.