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

[linuxtestproject.agent@gmail.com]

Hi Huaisheng,

On Mon Sep 14 11:23:59 2026 +0800, Huaisheng Ye wrote:
> hugemmap10: Account for memory policy in counter checks

> Note that a kernel patch has already been posted for solving Hugetlb
> reservations defect. Without that, hugemmap10 would fail when mapping .
> https://lore.kernel.org/all/20260909074642.7308-1-yehuaisheng@open-hieco.net/

The referenced kernel patch is not merged in mainline or the latest stable
release (7.3). Tests depending on unmerged kernel changes must use the
[STAGING] prefix and reside in runtest/staging rather than modifying
tests in default test suites.

> +static int node_isset(unsigned long node, const unsigned long *nodemask)
> +{
> +	return nodemask[node / ULONG_BITS] & (1UL << (node % ULONG_BITS));
> +}

On 64-bit systems, the return value truncates to a 32-bit int, yielding 0
for any node with (node % 64) >= 32. Return !!(...) instead.

> +		if ((unsigned long)hpages > allowed_free)
> +			shortfall = MAX(shortfall,
> +					(unsigned long)hpages - allowed_free);

allowed_free sums sysfs free_hugepages, which includes pages already
reserved by prior mappings. Comparing hpages against allowed_free without
accounting for reservations on those nodes undercalculates the shortfall
when prior reservations exist.

Verdict - Needs revision

Pre-existing issues:
- In per_iteration_cleanup(), map_fd[nr] > 0 is used to check file descriptor
  validity instead of != -1.

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