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

[Tejun Heo <tj@kernel.org>]

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? 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.

Thanks.

-- 
tejun