Re: thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

[email protected]
Newsgroups gmane.linux.ltp
Message-ID <[email protected]>
Hi Jan,

On Wed, Jul 1, 2026 at 13:12:38 +0200, Jan Polensky wrote:
> thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

> -#include "lapi/mmap.h"
> +#include "tst_checkpoint.h"
>  #include "tst_fuzzy_sync.h"
> +#include "tst_kconfig.h"
> +#include "tst_test.h"

The patch drops lapi/mmap.h but the test still uses MADV_HUGEPAGE (in
alloc_zero_page) and MADV_DONTNEED (multiple call sites). The fallback
defines for these constants live in lapi/mmap.h. On toolchains where
<sys/mman.h> does not provide them, this will fail to compile.

> +static void run_proc_mem_ptrace_race(void)
> +{
> +	/* After 1000 iterations, let tracee exit cleanly */
> +	SAFE_PTRACE(PTRACE_CONT, tracee_pid, NULL, NULL);
> +	SAFE_WAITPID(tracee_pid, &status, 0);

After run_proc_mem_ptrace_race() returns, the tracee has been reaped.
If the framework re-invokes run() (e.g. via -i 2), the next call to
SAFE_OPEN("/proc/<pid>/mem") will hit ENOENT and abort with TBROK.

The PROC_MEM_ALWAYS path survives re-invocation because
tst_fzsync_run_a() returns false immediately when runtime expires. The
ptrace path could either re-spawn the tracee in run(), or guard with
an early return when tracee_pid is no longer alive.

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.