Re: thp04: Fix PTRACE mode for CONFIG_PROC_MEM_FORCE_PTRACE=y

On Thu, Jul 02, 2026 at 08:58:25AM +0000, Andrea Cervesato wrote:
> 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-IBi9RG/[email protected]

Hi Andrea,

thanks, both issues are addressed in the next revision.

Regards,
Jan

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp