[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220711171130.6390600b@gandalf.local.home>
Date: Mon, 11 Jul 2022 17:11:30 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Tejun Heo <tj@...nel.org>
Cc: Qais Yousef <qais.yousef@....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, 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,
Waiman Long <longman@...hat.com>
Subject: Re: [PATCH] sched/schedutil: Fix deadlock between cpuset and cpu
hotplug when using schedutil
On Mon, 11 Jul 2022 10:58:28 -1000
Tejun Heo <tj@...nel.org> wrote:
> I don't think lockdep would be able to track CPU1 -> CPU2 dependency here
> unfortunately.
>
> > AFAIU:
> >
> >
> > CPU0 CPU1 CPU2
> >
> > // attach task to a different
> > // cpuset cgroup via sysfs
> > __acquire(cgroup_threadgroup_rwsem)
> >
> > // pring up CPU2 online
> > __acquire(cpu_hotplug_lock)
> > // wait for CPU2 to come online
Should there be some annotation here that tells lockdep that CPU1 is now
blocked on CPU2?
Then this case would be caught by lockdep.
-- Steve
> > // bringup cpu online
> > // call cpufreq_online() which tries to create sugov kthread
> > __acquire(cpu_hotplug_lock) copy_process()
> > cgroup_can_fork()
> > cgroup_css_set_fork()
> > __acquire(cgroup_threadgroup_rwsem)
> > // blocks forever // blocks forever // blocks forever
> >
Powered by blists - more mailing lists