From: Waiman Long <longman@redhat.com>
To: Tejun Heo <tj@kernel.org>, Zhang Qiao <zhangqiao22@huawei.com>
Cc: lizefan.x@bytedance.com, hannes@cmpxchg.org,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
"Michal Koutný" <mkoutny@suse.com>
Subject: Re: [Question] set_cpus_allowed_ptr() call failed at cpuset_attach()
Date: Fri, 14 Jan 2022 15:33:34 -0500 [thread overview]
Message-ID: <8bda2a8d-7faf-621d-c3c0-6351a49219ea@redhat.com> (raw)
In-Reply-To: <YeGi2yjRi/uZIF/2@slm.duckdns.org>
On 1/14/22 11:20, Tejun Heo wrote:
> (cc'ing Waiman and Michal and quoting whole body)
>
> Seems sane to me but let's hear what Waiman and Michal think.
>
> On Fri, Jan 14, 2022 at 09:15:06AM +0800, Zhang Qiao wrote:
>> Hello everyone
>>
>> I found the following warning log on qemu. I migrated a task from one cpuset cgroup to
>> another, while I also performed the cpu hotplug operation, and got following calltrace.
>>
>> This may lead to a inconsistency between the affinity of the task and cpuset.cpus of the
>> dest cpuset, but this task can be successfully migrated to the dest cpuset cgroup.
>>
>> Can we use cpus_read_lock()/cpus_read_unlock() to guarantee that set_cpus_allowed_ptr()
>> doesn't fail, as follows:
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index d0e163a02099..2535d23d2c51 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2265,6 +2265,7 @@ static void cpuset_attach(struct cgroup_taskset *tset)
>> guarantee_online_mems(cs, &cpuset_attach_nodemask_to);
>>
>> cgroup_taskset_for_each(task, css, tset) {
>> + cpus_read_lock();
>> if (cs != &top_cpuset)
>> guarantee_online_cpus(task, cpus_attach);
>> else
>> @@ -2274,6 +2275,7 @@ static void cpuset_attach(struct cgroup_taskset *tset)
>> * fail. TODO: have a better way to handle failure here
>> */
>> WARN_ON_ONCE(set_cpus_allowed_ptr(task, cpus_attach));
>> + cpus_read_unlock();
>>
>>
>> Is there a better solution?
>>
>> Thanks
The change looks OK to me. However, we may need to run the full set of
regression test to make sure that lockdep won't complain about potential
deadlock.
Cheers,
Longman
next prev parent reply other threads:[~2022-01-14 20:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <09ce5796-798e-83d0-f1a6-ba38a787bfc5@huawei.com>
2022-01-14 1:15 ` Zhang Qiao
2022-01-14 16:20 ` Tejun Heo
2022-01-14 20:33 ` Waiman Long [this message]
2022-01-17 2:25 ` Zhang Qiao
2022-01-17 4:35 ` Waiman Long
2022-01-17 6:27 ` Zhang Qiao
2022-01-17 6:25 ` Zhang Qiao
2022-01-19 13:02 ` Michal Koutný
2022-01-20 7:14 ` Zhang Qiao
2022-01-20 14:02 ` Michal Koutný
2022-01-21 8:33 ` Zhang Qiao
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=8bda2a8d-7faf-621d-c3c0-6351a49219ea@redhat.com \
--to=longman@redhat.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=mkoutny@suse.com \
--cc=tj@kernel.org \
--cc=zhangqiao22@huawei.com \
/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
all inboxes | Powered by JetHome®