[LTP] thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

[linuxtestproject.agent@gmail.com]

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