Re: freezing() returned false when the cgroup is being frozen

[Qu Wenruo <wqu@suse.com>]

在 2025/10/19 09:52, Tejun Heo 写道:
> Hello,
> 
> On Sat, Oct 18, 2025 at 07:32:16PM +1030, Qu Wenruo wrote:
> ...
>> Not familiar with cgroup, but it looks like the CGROUP_FREEZING bits are
>> only set during freezer_css_online(), but not sure if for the long running
>> ioctl case it's properly triggered.
>>
>> Anyway the freezing() checks can be worked around by checking pending
>> signals inside btrfs, as cgroup freezing will send a wakeup signal to the
>> process.
>>
>> Just curious if the freezing(current) is supposed to return false for the
>> cgroup freezing case.
> 
> cgroup1 and cgroup2 have completely separate freezer implementation.
> cgroup1's piggy back on the PM freezer which can freeze user and kthreads at
> arbitrary freezing points. While that's fine for system-wide PM freezing, it
> becomes a problem for cgroup freezing as users now can produce unkillable
> frozen processes at will, which can create interesting problems (e.g. IIRC
> the unkillable state can become transitive through ptrace).
> 
> Instead, cgroup2 freezer is a part of the task job control mechanism (the
> same thing that SIGTSTP/SIGSTOP uses) and a frozen task behaves as if it has
> sticky SIGSTOP signal pending. You can kill it, ptrace it and so on. As
> such, it doesn't interact with the PM freezing mechanism at all. I suppose
> you aren't talking about kthreads, right?

Yep, I'm only talking about user space process trapped in long ioctls.

> It's just user threads doing
> long-running ioctl's in btrfs code? If so, this should be no different from
> getting any other signals. ie. If the code can handle signals and
> task_work(), cgroup2 freezer should work fine too.

The freezing behavior is fine, my main concern is that freezing() 
function doesn't return true when cgroup (v2?) is freezing the process.

As you explained, since legacy cgroup is not that widely used anymore, I 
believe systemd is using cgroup v2, thus it's fully signal based, so 
freezing() is no longer the proper way to detect such freezing, but 
signal_pending().

Maybe some comment on freezing() about this?

Thanks,
Qu

> 
> Thanks.
>