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

[Waiman Long <longman@redhat.com>]

On 7/14/26 9:24 PM, Tao Cui wrote:
>
> 在 2026/7/15 06:09, Tejun Heo 写道:
>> Hello, Waiman.
>>
>>> +	usleep(1000);
>>>   	if (cg_check_frozen(cgroup, true))
>>>   		goto cleanup;
>> A fixed 1ms sleep only hides the race. On a loaded machine or a slow arch
>> (you mention ppc64) the refreeze can take longer than 1ms, and the test
>> reads the unfrozen state and fails anyway.
>>
>> The freezer test already has a way to wait for this properly.
>> cg_prepare_for_wait() sets up an inotify watch on cgroup.events and
>> cg_wait_for() blocks until it changes. cg_enter_and_wait_for_frozen() shows
>> the pattern: loop cg_wait_for() then cg_check_frozen(). The cgroup always
>> ends up frozen, so looping until cg_check_frozen() reports frozen is
>> reliable and doesn't depend on timing.
>>
>> Can you respin using that instead of usleep()?
>>
>> Also, temporaily -> temporarily, in both the changelog and the comment.
>>
> Hi Tejun, Waiman,
>
> I ran into a similar issue a while back and can add a data point on
> the reproducibility: when running the full cgroup selftest suite, a
> few cases -- test_cgfreezer_ptrace and test_cgfreezer_stopped -- fail
> intermittently (around 40-70% on VMs), yet each failing case passes
> reliably when run on its own. That points at state carried across
> tests rather than a per-test bug, which is also why a fixed sleep/retry
> is fragile.
>
> On the "unfrozen state" above, I traced where CGRP_FROZEN actually gets
> cleared. When the frozen tracee is woken by PTRACE_INTERRUPT,
> JOBCTL_TRAP_STOP takes priority over JOBCTL_TRAP_FREEZE in get_signal(),
> so the task enters ptrace_stop() instead of going back to
> do_freezer_trap(). With debug printk in cgroup_update_frozen_flag() and
> cgroup_leave_frozen(), the cg_test_ptrace trace shows:
>
>    0 -> 1  nr_frozen=1  task_count=1   /* initial freeze            */
>    1 -> 0  nr_frozen=0  task_count=1   /* dec, task still in cgroup */
>    0 -> 1  nr_frozen=0  task_count=0   /* task left cgroup          */
>
> The 1 -> 0 step (nr_frozen 1->0 while task_count is still 1) is
> cgroup_dec_frozen_cnt(), called from cgroup_leave_frozen(true) at the
> end of ptrace_stop() (signal.c:2479) when the tracee is woken by
> PTRACE_DETACH. That clears CGRP_FROZEN until the task loops back into
> do_freezer_trap() and re-enters the frozen state -- the transient
> unfrozen window the test hits.
>
> As a kernel-side attempt I changed cgroup_enter_frozen() so it no longer
> returns early when current->frozen is already true: css_set_lock is
> taken before the check and, if CGRP_FREEZE is still set,
> cgroup_update_frozen() is called to re-verify the cgroup frozen state
> when a frozen task is handed off to ptrace.

get_signal() => ptrace_do_notify() => ptrace_stop() is where I saw the 
cgroup became unfrozen. Later cgroup_enter_frozen() is called to be 
frozen again. I do my testing mostly on bare metal and I don't see 
failure in x86, but I do see intermittent failures in arm64 and ppc64le. 
Also the clearing and setting of the frozen flag and the reading of 
frozen flag is from different processes running on different CPUs. I 
suppose the PTRACE_DETACH operation is synchronous. That is why I 
suspect it can be a racing issue where the frozen flag is seen to be set 
in one CPU while the other CPU may still see it cleared. This kind of 
racing issues are much more visible in archs with weak memory model.

Cheers,
Longman