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

[Andrea Cervesato]

Hi Jan,

> 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.

This is correct. Please always use lapi/mmap.h instead of the
sys/mman.h. In this way we are sure to fallback to an existing
value and LTP compiles in any machine that doesn't have those
definitions.

> 
> > +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.

This is also correct. Always run the test with `-i` as well.
Also, take a look at tst_reap_children(), because it looks like
we are duplicating the same functionality with SAFE_WAITPID() here.

--
Andrea Cervesato
SUSE QE Automation Engineer Linux
andrea.cervesato@suse.com