[LTP] hugemmap/hugemmap41: Migrate ptrace-write-hugepage from libhugetlbfs

linuxtestproject.agent@gmail.com linuxtestproject.agent@gmail.com
Sat Aug 8 19:33:21 CEST 2026


Hi Pavithra,

On Sat, Aug 8, 2026, Pavithra wrote:
> hugemmap/hugemmap41: Migrate ptrace-write-hugepage from libhugetlbfs

> +/hugetlb/hugemmap/hugemmap41

Could this entry be placed in
testcases/kernel/mem/hugetlb/hugemmap/.gitignore as /hugemmap41 instead?
New test binaries should be ignored in their leaf test directory rather
than extending the legacy testcases/kernel/mem/.gitignore list.

> +	p = SAFE_MMAP(NULL, hpage_size, PROT_READ|PROT_WRITE, MAP_SHARED,

Could spaces be added around the "|" operator? make check-hugemmap41
reports this line as a kernel style violation.

> +	TST_EXP_EQ_LU((unsigned long)TST_RET, CONST);
> +}
> +
> +static void run_test(void)
> +{
> [...]
> +	do_poke(cpid, p);
> +	do_poke(cpid, p + getpagesize());
> [...]
> +	tst_res(TPASS, "ptrace write to hugepage succeeded");

Could the unconditional TPASS be removed? If either equality check reports
a mismatch, this line still claims that the operation succeeded. The two
TST_EXP_EQ_LU() calls already report their own pass results.

> +	.tags = (struct tst_tag[]) {
> +		{"linux-git", "ebed4bfc8da8"},
> +		{}
> +	},

Which ptrace regression is this tag intended to identify? ebed4bfc8da8 is
"hugetlb: fix absurd HugePages_Rsvd", which fixes reservation accounting
after truncating a mapped hugetlbfs file. This test neither truncates the
file nor checks HugePages_Rsvd, so a failure would print an unrelated
missing-fix hint.

Could the tag be removed, or replaced with the full 40-character hash of
the actual ptrace/hugetlb fix?

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


More information about the ltp mailing list