From: linuxtestproject.agent@gmail.com
To: Jan Polensky <japo@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] thp04: Add ptrace mode and fix tracee stop synchronization
Date: Thu, 9 Jul 2026 16:37:54 +0000 [thread overview]
Message-ID: <20260709163754.4041-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260709143551.147268-1-japo@linux.ibm.com>
Hi Jan,
On July 09, 2026, Jan Polensky wrote:
> thp04: Add ptrace mode and fix tracee stop synchronization
> + effective_mode = user_mode;
> +
> + /* Probe direct /proc/self/mem writes only if not explicitly set to ptrace */
> + if (!explicit_mode || user_mode == PROC_MEM_ALWAYS) {
> + ...
> + effective_mode = PROC_MEM_PTRACE;
> + }
> +
> + /* Ptrace mode: tracee will be spawned in run() for each iteration */
> + if (effective_mode == PROC_MEM_PTRACE)
> + return;
> +
> + tst_brk(TCONF, "Writes to /proc/self/mem disabled in kernel policy");
The final tst_brk() appears unreachable. Every code path through setup()
either returns or calls tst_brk() before reaching this line:
- Probe succeeds (PROC_MEM_ALWAYS path): early return inside the block.
- Probe fails with non-EIO: tst_brk(TBROK) inside the block.
- Probe fails with EIO and explicit_mode && user_mode==PROC_MEM_ALWAYS:
tst_brk(TCONF) inside the block.
- Probe fails with EIO otherwise: effective_mode is set to PROC_MEM_PTRACE
inside the block, then the "if (PROC_MEM_PTRACE) return" fires.
- Explicit ptrace mode (block skipped): effective_mode==PROC_MEM_PTRACE
was set before the block, so "if (PROC_MEM_PTRACE) return" fires.
- Explicit never mode: tst_brk(TCONF, "...on kernel cmdline") fires
inside the params[0].found block; execution does not continue.
Is there a case this was intended to handle that is now missing?
> + for (i = 0; i < PTRACE_TEST_ITERATIONS; i++) {
> + ...
> + /* Wait for tracee to stop itself with raise(SIGSTOP) */
> + SAFE_WAITPID(tracee_pid, &status, 0);
> +
> + if (!WIFSTOPPED(status) || WSTOPSIG(status) != SIGSTOP)
> + tst_brk(TBROK, "Tracee did not stop with SIGSTOP: %s",
> + tst_strstatus(status));
> + }
When the tracee detects page pollution it calls:
tst_res(TFAIL, "Huge zero page was polluted");
child_cleanup();
exit(1);
The SAFE_WAITPID above then returns with WIFEXITED(status)=true, which
triggers tst_brk(TBROK, "Tracee did not stop with SIGSTOP: exited, status=1").
The test output becomes:
TFAIL: Huge zero page was polluted
TBROK: Tracee did not stop with SIGSTOP: exited, status=1
The TFAIL is propagated correctly via the LTP result mechanism.
However, the TBROK message "Tracee did not stop with SIGSTOP" describes
an infrastructure anomaly rather than the actual failure (page pollution).
Would it be clearer to check WIFEXITED explicitly and omit the TBROK when
the tracee has already reported a result?
Verdict - Needs revision
Pre-existing issues:
thread_run_always(), line visible in context (unchanged from original):
/* Wait for dirty page handling before next madvise() */
usleep(10);
This is sleep-based synchronization. It was present before this patch and
is not introduced here, but worth noting for a follow-up cleanup.
---
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
next prev parent reply other threads:[~2026-07-09 16:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 14:35 [LTP] [PATCH v5 1/1] thp04: Add ptrace mode and fix tracee stop synchronization Jan Polensky
2026-07-09 16:37 ` linuxtestproject.agent [this message]
2026-07-09 17:59 ` [LTP] " Jan Polensky
-- strict thread matches above, loose matches on Subject: below --
2026-07-09 17:59 [LTP] [PATCH v6 1/1] " Jan Polensky
2026-07-09 18:56 ` [LTP] " linuxtestproject.agent
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=20260709163754.4041-1-linuxtestproject.agent@gmail.com \
--to=linuxtestproject.agent@gmail.com \
--cc=japo@linux.ibm.com \
--cc=ltp@lists.linux.it \
/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.