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
