From: Prateek Sood <prsood@codeaurora.org>
To: Tejun Heo <tj@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
avagin@gmail.com, mingo@kernel.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, sramana@codeaurora.org,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency
Date: Mon, 15 Jan 2018 17:32:18 +0530 [thread overview]
Message-ID: <3c9b2a2d-ede4-1242-418a-353ec9f78db3@codeaurora.org> (raw)
In-Reply-To: <20180102161656.GD3668920@devbig577.frc2.facebook.com>
On 01/02/2018 09:46 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Dec 29, 2017 at 02:07:16AM +0530, Prateek Sood wrote:
>> task T is waiting for cpuset_mutex acquired
>> by kworker/2:1
>>
>> sh ==> cpuhp/2 ==> kworker/2:1 ==> sh
>>
>> kworker/2:3 ==> kthreadd ==> Task T ==> kworker/2:1
>>
>> It seems that my earlier patch set should fix this scenario:
>> 1) Inverting locking order of cpuset_mutex and cpu_hotplug_lock.
>> 2) Make cpuset hotplug work synchronous.
>>
>> Could you please share your feedback.
>
> Hmm... this can also be resolved by adding WQ_MEM_RECLAIM to the
> synchronize rcu workqueue, right? Given the wide-spread usages of
> synchronize_rcu and friends, maybe that's the right solution, or at
> least something we also need to do, for this particular deadlock?
>
> Again, I don't have anything against making the domain rebuliding part
> of cpuset operations synchronous and these tricky deadlock scenarios
> do indicate that doing so would probably be beneficial. That said,
> tho, these scenarios seem more of manifestations of other problems
> exposed through kthreadd dependency than anything else.
>
> Thanks.
>
Hi TJ,
Thanks for suggesting WQ_MEM_RECLAIM solution.
My understanding of WQ_MEM_RECLAIM was that it needs to be used for
cases where memory pressure could cause deadlocks.
In this case it does not seem to be a memory pressure issue.
Overloading WQ_MEM_RECLAIM usage for solution to another problem
is the correct approach?
This scenario can be resolved by using WQ_MEM_RECLAIM and a separate
workqueue for rcu. But there seems to be a possibility in future if
any cpu hotplug callbacks use other predefined workqueues which do not
have WQ_MEM_RECLAIM option.
Please let me know your feedback on this.
Thanks
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project
next prev parent reply other threads:[~2018-01-15 12:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CANaxB-zT+sz=z1FFk5npnwMySdfKCBZDkM+P+=JXDkCXbh=rCw@mail.gmail.com>
2017-11-28 11:35 ` [PATCH] cgroup/cpuset: fix circular locking dependency Prateek Sood
2017-12-04 5:14 ` Prateek Sood
2017-12-04 20:22 ` Tejun Heo
2017-12-04 22:58 ` Tejun Heo
2017-12-04 23:01 ` Peter Zijlstra
2017-12-08 9:40 ` Prateek Sood
2017-12-08 11:45 ` Prateek Sood
2017-12-11 15:32 ` Tejun Heo
2017-12-13 14:28 ` Prateek Sood
2017-12-13 15:40 ` Tejun Heo
2017-12-15 8:54 ` Prateek Sood
2017-12-15 13:22 ` Tejun Heo
2017-12-15 19:06 ` Prateek Sood
2017-12-19 7:26 ` [PATCH] cgroup: Fix deadlock in cpu hotplug path Prateek Sood
2017-12-19 13:39 ` Tejun Heo
2017-12-11 15:20 ` [PATCH] cgroup/cpuset: fix circular locking dependency Tejun Heo
2017-12-13 7:50 ` Prateek Sood
2017-12-13 16:06 ` Tejun Heo
2017-12-15 19:04 ` Prateek Sood
2017-12-28 20:37 ` Prateek Sood
2018-01-02 16:16 ` Tejun Heo
2018-01-02 17:44 ` Paul E. McKenney
2018-01-02 18:01 ` Paul E. McKenney
2018-01-08 12:28 ` Tejun Heo
2018-01-08 13:47 ` [PATCH wq/for-4.16 1/2] workqueue: separate out init_rescuer() Tejun Heo
2018-01-08 13:47 ` [PATCH wq/for-4.16 2/2] workqueue: allow WQ_MEM_RECLAIM on early init workqueues Tejun Heo
2018-01-08 22:52 ` [PATCH] cgroup/cpuset: fix circular locking dependency Paul E. McKenney
2018-01-09 0:31 ` Paul E. McKenney
2018-01-09 3:42 ` Tejun Heo
2018-01-09 4:20 ` Paul E. McKenney
2018-01-09 13:44 ` Tejun Heo
2018-01-09 15:21 ` Paul E. McKenney
2018-01-09 15:37 ` Tejun Heo
2018-01-09 16:00 ` Paul E. McKenney
2018-01-10 20:08 ` Paul E. McKenney
2018-01-10 21:41 ` Tejun Heo
2018-01-10 22:10 ` Paul E. McKenney
2018-01-15 12:02 ` Prateek Sood [this message]
2018-01-16 16:27 ` Tejun Heo
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=3c9b2a2d-ede4-1242-418a-353ec9f78db3@codeaurora.org \
--to=prsood@codeaurora.org \
--cc=avagin@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=sramana@codeaurora.org \
--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;
as well as URLs for NNTP newsgroup(s).