Re: [PATCH v2] selftests/cgroup: Fix intermittent test_cgfreezer_ptrace test failures
Waiman Long <[email protected]>
| Newsgroups | org.kernel.vger.cgroups,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
On 7/15/26 5:36 AM, Michal Koutný wrote: > Hi. > > On Tue, Jul 14, 2026 at 11:54:46PM -0400, Waiman Long <[email protected]> wrote: >> It is found that the test_cgfreezer_ptrace test of test_freezer can >> intermittently fail on some architectures like arm64 and ppc64. >> >> After further tracing of the mechanics of the test_cgfreezer_ptrace test, >> it is found that the ptrace(PTRACE_DETACH) call will spawn another process >> to perform the detach > I'm reading kernel/ptrace.c and cannot find a new task creation. > I'm curious what is this "another process"? I should be more clear about that. It is not exec'ing a new binary. It is just spawning a child process/thread which still has the same name but different pid as well as running on a different CPU which are what I am tracking. > > (Or is it referring to the child_fn() process from > test_cgfreezer_ptrace()? Then I'm suspicous about the transitional > unfreezing of it after PTRACE_DETACH. Wasn't it rightful expectation of > the test that the cgroup remains contiguously frozen?) As said in my reply to the v1 thread, the detaching process includes a call to ptrace_stop() which will unfreeze the cgroup temporarily and then go back to frozen afterward. It is this transitional unfreeze/freeze that may cause the test to fail if it detects the transitional non-frozen state. My patch is to make sure that it can see the final the frozen state and avoid reporting failure. Cheers, Longman > >> by temporarily unfreezes the cgroup and then freezes >> it again afterward during the detaching process. The reading of the >> frozen flag from cgroup.events is done by the main test_freezer process >> running probably on a different CPU. As a result, racing is possible and >> the intermediate unfrozen state can be read leading to occasional test >> failures especially on architectures with a weak memory model like arm64. > What state would the task be in during this window? > > Thanks, > Michal