Linux Test Project
 help / color / mirror / Atom feed
From: linuxtestproject.agent@gmail.com
To: Samir Mulani <samir@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] hugetlb/hugeshmat: Add hugeshmat06 migrated from libhugetlbfs shm-perms
Date: Thu, 20 Aug 2026 18:40:02 +0000	[thread overview]
Message-ID: <20260820184002.4137-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260820125552.47435-1-samir@linux.ibm.com>

Hi Samir,

On Aug 20, 2026, Samir Mulani wrote:
> hugetlb/hugeshmat: Add hugeshmat06 migrated from libhugetlbfs shm-perms

> #define HPAGES_IN_SEG	4
> #define MAX_CHILDREN	128
>
> 	iterations = MIN((long)tst_hugepages, (long)MAX_CHILDREN);

Could the iteration count retain the original test's exhaustion guarantee?
Each leaked attach reserves HPAGES_IN_SEG pages, so a pool containing N
hugepages requires more than N / HPAGES_IN_SEG attaches to expose the leak.
The original test calculated that value plus one.

With this cap, one execution can pass without detecting the bug when the pool
contains 512 or more hugepages. Even the "-i 5" runtest entry is insufficient
at 2560 or more. Could the count instead be derived from the pool and segment
sizes, including the final attach that exceeds the pool?

> 			if (shmaddr == (void *)-1) {
> 				tst_res(TFAIL | TERRNO,
> 					"Child %d: shmat() failed, hugepage reservation pool may be exhausted",
> 					getpid());
> 				exit(EXIT_FAILURE);
> 			}

Could the child exit successfully after reporting TFAIL?
tst_reap_children() converts this nonzero status into an additional TBROK
("Invalid child exit value") and aborts the parent. LTP already propagates the
child's tst_res() result, so the regression should remain a TFAIL rather than
also becoming a broken-test result.

> static struct tst_test test = {
> 	.needs_root	 = 1,

This is described as a regression test, but the test has no .tags entry.
Could the corresponding linux-git regression fix tag be added?

> +/hugetlb/hugeshmat/hugeshmat06

Could this binary instead be ignored by
testcases/kernel/mem/hugetlb/hugeshmat/.gitignore as /hugeshmat06? New test
binaries should use a leaf-directory .gitignore rather than the shared
testcases/kernel/mem/.gitignore.

> /*\
>  * Tests shared memory behavior when multiple processes attach to a
>  * hugepage-backed segment with different permissions.

Could the exported description explain why root is required? The test sets
.needs_root because the framework adjusts the hugepage pool and mounts
hugetlbfs.

>  * pool.  This is detected by using raw shmat() in each child so that a

Could shmat() use the ":manpage:`shmat(2)`" role here? Syscalls in exported
test descriptions should use their man-page role.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2026-08-20 18:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 12:55 [LTP] [PATCH v5] hugetlb/hugeshmat: Add hugeshmat06 migrated from libhugetlbfs shm-perms Samir Mulani
2026-08-20 18:40 ` linuxtestproject.agent [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-08-20  4:25 [LTP] [PATCH v4] " Samir Mulani
2026-08-20 10:33 ` [LTP] " linuxtestproject.agent
2026-08-20 16:49   ` Samir M

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260820184002.4137-1-linuxtestproject.agent@gmail.com \
    --to=linuxtestproject.agent@gmail.com \
    --cc=ltp@lists.linux.it \
    --cc=samir@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox