[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuQ8FWtrMsgDmGAr@slm.duckdns.org>
Date: Fri, 29 Jul 2022 09:59:17 -1000
From: Tejun Heo <tj@...nel.org>
To: Qais Yousef <qais.yousef@....com>
Cc: Xuewen Yan <xuewen.yan94@...il.com>,
Waiman Long <longman@...hat.com>,
Xuewen Yan <xuewen.yan@...soc.com>, rafael@...nel.org,
viresh.kumar@...aro.org, mingo@...hat.com, peterz@...radead.org,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
mgorman@...e.de, bristot@...hat.com, linux-kernel@...r.kernel.org,
ke.wang@...soc.com, xuewyan@...mail.com, linux-pm@...r.kernel.org,
Lukasz Luba <Lukasz.Luba@....com>, pengcheng.lai@...soc.com
Subject: Re: [PATCH] sched/schedutil: Fix deadlock between cpuset and cpu
hotplug when using schedutil
On Fri, Jul 29, 2022 at 09:39:49AM +0100, Qais Yousef wrote:
> I *think* it's because we haven't removed cpus_read_lock() from
> cpuset_attach(). So we end up holding the lock twice in the same path. Since we
> hold it unconditionally now, we should remove cpuset dependency on
> cpus_read_lock() I believe.
Ah, yeah, that's because pending write locker makes future reader lockers
wait, so even if we're holding read lock, if we try to read lock again, we
end up waiting. I'll make the cpus_read_lock() unconditional in cgroup core
and drop it from cpuset's attach operation.
Thanks.
--
tejun
Powered by blists - more mailing lists