Re: [PATCH v2] selftests/cgroup: Fix intermittent test_cgfreezer_ptrace test failures

[Waiman Long <longman@redhat.com>]

On 7/15/26 5:36 AM, Michal Koutný wrote:
> Hi.
>
> On Tue, Jul 14, 2026 at 11:54:46PM -0400, Waiman Long <longman@redhat.com> 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