From: Chen Ridong <chenridong@huaweicloud.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Michal Koutn?? <mkoutny@suse.com>,
rafael@kernel.org, pavel@kernel.org, timvp@google.com,
tj@kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, lujialin4@huawei.com,
chenridong@huawei.com
Subject: Re: [PATCH next] sched,freezer: prevent tasks from escaping being frozen
Date: Fri, 4 Jul 2025 18:25:12 +0800 [thread overview]
Message-ID: <85fc85e8-af92-4d58-8271-9bf4aeb0a63d@huaweicloud.com> (raw)
In-Reply-To: <20250704075718.GA2001818@noisy.programming.kicks-ass.net>
On 2025/7/4 15:57, Peter Zijlstra wrote:
> On Fri, Jul 04, 2025 at 11:11:52AM +0800, Chen Ridong wrote:
>
> Your patches are mangled; please educate your MUA.
>
Hi Peter,
Thank you for your review and feedback
Apologies for the formatting issues in the patch.
>> --- a/kernel/freezer.c
>> +++ b/kernel/freezer.c
>> @@ -71,19 +71,20 @@ bool __refrigerator(bool check_kthr_stop)
>> for (;;) {
>> bool freeze;
>>
>> - raw_spin_lock_irq(¤t->pi_lock);
>> - WRITE_ONCE(current->__state, TASK_FROZEN);
>> - /* unstale saved_state so that __thaw_task() will wake
>> us up */
>> - current->saved_state = TASK_RUNNING;
>> - raw_spin_unlock_irq(¤t->pi_lock);
>> -
>> spin_lock_irq(&freezer_lock);
>> - freeze = freezing(current) && !(check_kthr_stop &&
>> kthread_should_stop());
>> + freeze = (freezing(current) || !cgroup_thawed(current))
>> + && !(check_kthr_stop && kthread_should_stop());
>
> This makes no sense to me; why can't this stay in cgroup_freezing()?
>
> Also, can someone please fix that broken comment style there.
>
The change relates to commit cff5f49d433f ("cgroup_freezer: cgroup_freezing: Check if not frozen"),
which modified cgroup_freezing() to verify the FROZEN flag isn't set. The freezing(p) will return
false if the cgroup is frozen.
>> spin_unlock_irq(&freezer_lock);
>>
>> if (!freeze)
>> break;
>>
>> + raw_spin_lock_irq(¤t->pi_lock);
>> + WRITE_ONCE(current->__state, TASK_FROZEN);
>> + /* unstale saved_state so that __thaw_task() will wake
>> us up */
>> + current->saved_state = TASK_RUNNING;
>> + raw_spin_unlock_irq(¤t->pi_lock);
>> +
>
> And I'm not quite sure I understand this hunk either. If we bail out,
> current->__state is reset to TASK_RUNNING, so what's the problem?
The issue occurs in this race scenario:
echo FROZEN > freezer.state
freeze_cgroup()
freeze_task()
fake_signal_wake_up() // wakes task to freeze it
In task context:
get_signal
try_to_freeze
__refrigerator
WRITE_ONCE(current->__state, TASK_FROZEN); // set TASK_FROZEN
// race: cgroup state updates to frozen
freezing(current) now return false
// We bail out, the task is not frozen but it should be frozen.
I hope this explanation clarifies the issue I encountered.
Here's the corrected format patch:
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 8d530d0949ff..16e98a6b497a 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -71,19 +71,20 @@ bool __refrigerator(bool check_kthr_stop)
for (;;) {
bool freeze;
- raw_spin_lock_irq(¤t->pi_lock);
- WRITE_ONCE(current->__state, TASK_FROZEN);
- /* unstale saved_state so that __thaw_task() will wake us up */
- current->saved_state = TASK_RUNNING;
- raw_spin_unlock_irq(¤t->pi_lock);
-
spin_lock_irq(&freezer_lock);
- freeze = freezing(current) && !(check_kthr_stop && kthread_should_stop());
+ freeze = (freezing(current) || !cgroup_thawed(current))
+ && !(check_kthr_stop && kthread_should_stop());
spin_unlock_irq(&freezer_lock);
if (!freeze)
break;
+ raw_spin_lock_irq(¤t->pi_lock);
+ WRITE_ONCE(current->__state, TASK_FROZEN);
+ /* unstale saved_state so that __thaw_task() will wake us up */
+ current->saved_state = TASK_RUNNING;
+ raw_spin_unlock_irq(¤t->pi_lock);
+
was_frozen = true;
schedule();
}
Best regards,
Ridong
next prev parent reply other threads:[~2025-07-04 10:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-03 13:34 [PATCH next] sched,freezer: prevent tasks from escaping being frozen Chen Ridong
2025-07-03 17:01 ` Michal Koutný
2025-07-04 3:02 ` Chen Ridong
2025-07-04 3:11 ` Chen Ridong
2025-07-04 7:57 ` Peter Zijlstra
2025-07-04 10:25 ` Chen Ridong [this message]
2025-07-07 4:02 ` Chen Ridong
2025-07-07 10:10 ` Peter Zijlstra
2025-07-07 11:32 ` Chen Ridong
2025-07-08 7:28 ` Peter Zijlstra
2025-07-08 15:35 ` Tim Van Patten
2025-07-10 15:44 ` Michal Koutný
2025-07-11 0:51 ` Chen Ridong
2025-07-07 16:38 ` Michal Koutný
2025-07-08 1:38 ` Chen Ridong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85fc85e8-af92-4d58-8271-9bf4aeb0a63d@huaweicloud.com \
--to=chenridong@huaweicloud.com \
--cc=chenridong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lujialin4@huawei.com \
--cc=mkoutny@suse.com \
--cc=pavel@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=timvp@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox