Re: [LTP] hugemmap10: Account for memory policy in mmap counter checks

[linuxtestproject.agent@gmail.com]

Hi Huaisheng,

On 2026-10-10, Huaisheng Ye wrote:
> hugemmap10: Account for memory policy in mmap counter checks

--- [PATCH 1/3] ---

> +	mode &= ~MPOL_MODE_FLAGS;
> +	/* Hugetlb ignores a bind policy that no longer overlaps the cpuset. */
> +	use_bind = mode == MPOL_BIND &&
> +		nodemasks_intersect(policy_nodemask, cpuset_nodemask, maxnode);

Medium: get_mempolicy() returns the original user mask for
MPOL_F_RELATIVE_NODES, not physical node IDs. With cpuset {1,2}, relative
bind {0}, and one free hugepage on node 2 only, this falls back to the
whole cpuset and predicts zero surplus although the effective bind node
1 needs one surplus page. Preserve the mode flags and resolve the
relative mask against allowed memory nodes, including folding, before
intersecting it or applying the fallback.

--- [PATCH 2/3] ---

>  hugemmap10 hugemmap10
> +hugemmap10 hugemmap10 -n

Medium: both variants use the same runtest identifier, which Kirk uses
for session restore and reboot recovery. If the default invocation
completes before an interruption, the pending -n invocation is also
considered completed and skipped. Give it a distinct identifier, for
example "hugemmap10_noreserve hugemmap10 -n".

--- [PATCH 3/3] ---

> +	/* An unreserved private mapping creates its reservation on fault. */

Low: MAP_NORESERVE faults allocate unreserved hugepages; they do not
create a hugetlb mapping reservation. hugetlb_reserve_pages() returns
before creating the private reservation map, and HugePages_Rsvd stays
unchanged, as this branch's er = prev_resv already expects. Describe this
as fault-time allocation in the comment and commit message.

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