From: linuxtestproject.agent@gmail.com
To: Samir Mulani <samir@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] hugemmap: Migrate alloc-instantiate-race test from libhugetlbfs
Date: Tue, 18 Aug 2026 20:27:30 +0000 [thread overview]
Message-ID: <20260818202730.9105-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260818143106.43797-1-samir@linux.ibm.com>
Hi Samir,
On August 18, 2026, Samir Mulani wrote:
> hugemmap: Migrate alloc-instantiate-race test from libhugetlbfs
> Migrate the alloc-instantiate-race.c test from libhugetlbfs [1] to LTP
> as hugemmap36.
Could this be corrected to hugemmap42, which is the test added by this
patch?
> +hugemmap42 hugemmap42
Could a second runtest entry exercise "-m private"? Without an option,
setup() defaults to MAP_SHARED, so the new pthread path is not run by the
hugetlb suite.
> + err = sched_setaffinity(getpid(), mask_size, cpuset);
Could this pass 0 as the pid? sched_setaffinity() applies the mask to the
thread ID supplied in pid. In the MAP_PRIVATE path, getpid() identifies the
thread-group leader for both pthreads, so both racers change the main
thread's affinity and remain unpinned.
> + p_sync = SAFE_MMAP(NULL, (totpages - 1) * hpage_size,
> + PROT_READ | PROT_WRITE, MAP_SHARED, fd_sync, 0);
> +
> + run_race(race_type);
Could each hugepage in p_sync be written before run_race()? mmap() without
MAP_POPULATE does not fault these pages in. Consequently all free hugepages
remain available to the racers instead of only the final page, and the
allocation race is not exercised. The source test explicitly touches each
page for this reason.
> + if (p_sync != MAP_FAILED) {
> + unsigned long totpages = SAFE_READ_MEMINFO(MEMINFO_HPAGE_FREE);
> +
> + SAFE_MUNMAP(p_sync, totpages * tst_get_hugepage_size());
> + }
Could the exact length passed to mmap() be saved and reused here? The
current free-page count is not the mapping length. On an abort with the
current code it is one page larger, and munmap() may remove an adjacent
mapping. After the pages are faulted in, a pre-existing hugepage pool can
instead make it smaller and leave part of p_sync mapped.
> + {NULL, NULL, NULL}
Could this use the standard empty sentinel "{}"? check-hugemmap42 reports
LTP-005 for this options array.
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
prev parent reply other threads:[~2026-08-18 20:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 14:31 [LTP] [PATCH v6] hugemmap: Migrate alloc-instantiate-race test from libhugetlbfs Samir Mulani
2026-08-18 20:27 ` linuxtestproject.agent [this message]
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=20260818202730.9105-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.