[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAB8ipk-72V-bYRfL-VcSRSyXTeQqkBVj+1d5MHSVV5CTar9a0Q@mail.gmail.com>
Date: Tue, 9 Aug 2022 10:02:44 +0800
From: Xuewen Yan <xuewen.yan94@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: Qais Yousef <qais.yousef@....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
Hi Tejun
On Sat, Jul 30, 2022 at 3:59 AM Tejun Heo <tj@...nel.org> wrote:
>
> 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.
I revert the following patch which add the cpus_read_lock() in
cpuset's attach and have test for a while. And the deadlock has not
reproduced.
https://lore.kernel.org/all/20220121101210.84926-1-zhangqiao22@huawei.com/
But I do not know the risk with reverting the patch..
Thanks!
BR
--
xuewen
>
> Thanks.
>
> --
> tejun
Powered by blists - more mailing lists