From: linuxtestproject.agent@gmail.com
To: Jan Polensky <japo@linux.ibm.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] thp04: group runtime state and skip when /proc/self/mem writes are blocked
Date: Wed, 12 Aug 2026 15:01:16 +0000 [thread overview]
Message-ID: <20260812150116.4069-1-linuxtestproject.agent@gmail.com> (raw)
In-Reply-To: <20260812132901.202632-2-japo@linux.ibm.com>
Hi Jan,
On Aug 12, 2026, Jan Polensky wrote:
> thp04: group runtime state and skip when /proc/self/mem writes are blocked
--- [PATCH 1/3] ---
> + SAFE_MPROTECT((void *)state->write_thp, state->thp_size, PROT_READ);
> [...]
> + *state->write_ptr = 0;
Could the mapping be made writable again before this direct store, or could
the value be reset through /proc/self/mem? At this point write_ptr points
inside a PROT_READ mapping, so a successful probe is followed by SIGSEGV in
setup() and the test never runs.
--- [PATCH 2/3] ---
> + if (TST_RET == sizeof(test_val)) {
> + tst_res(TFAIL,
> + "Write to /proc/self/mem succeeded under CONFIG_PROC_MEM_FORCE_PTRACE=y");
Could this successful write report TCONF, as described in the commit
message? The proc_mem.force_override=always boot parameter overrides the
Kconfig default, so .needs_kconfigs does not prove that the ptrace policy is
active at runtime. A successful write is therefore valid on that boot and
must not produce TFAIL.
--- [PATCH 3/3] ---
> + TST_CHECKPOINT_WAKE(1);
> + SAFE_PTRACE(PTRACE_INTERRUPT, tracee_pid, NULL, NULL);
> + SAFE_WAITPID(tracee_pid, &status, 0);
Could checkpoint 1 remain blocked until after PTRACE_INTERRUPT has produced
the initial stop? The child can currently check the initial zero value and
raise(SIGSTOP) before the interrupt takes effect. If the wait observes that
stop, every write is checked one iteration late; after the final write the
child reaches pause() without checking or stopping, and the parent hangs in
SAFE_WAITPID().
> + SAFE_WRITE(SAFE_WRITE_ALL, memfd, &write_val, sizeof(write_val));
Could this write be probed explicitly and EIO handled as TCONF? The released
kernel permits proc_mem.force_override=never to override
CONFIG_PROC_MEM_FORCE_PTRACE. On that valid boot, FOLL_FORCE remains disabled
even for an active tracer and SAFE_WRITE() aborts the test as TBROK.
> + tracee_pid = 0;
Could the trailing whitespace on the following blank line be removed? It
causes git diff --check to fail.
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
next prev parent reply other threads:[~2026-08-12 15:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 13:28 [LTP] [PATCH v4 0/3] Handle FORCE_PTRACE in thp04 and add ptrace coverage Jan Polensky
2026-08-12 13:28 ` [LTP] [PATCH v4 1/3] thp04: group runtime state and skip when /proc/self/mem writes are blocked Jan Polensky
2026-08-12 15:01 ` linuxtestproject.agent [this message]
2026-08-12 13:28 ` [LTP] [PATCH v4 2/3] ptrace: add test for /proc/self/mem write rejection Jan Polensky
2026-08-12 13:28 ` [LTP] [PATCH v4 3/3] ptrace: add test for /proc/pid/mem writes under ptrace Jan Polensky
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=20260812150116.4069-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox