From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Tejun Heo <tj@kernel.org>
Cc: Prateek Sood <prsood@codeaurora.org>,
Peter Zijlstra <peterz@infradead.org>,
avagin@gmail.com, mingo@kernel.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, sramana@codeaurora.org
Subject: Re: [PATCH] cgroup/cpuset: fix circular locking dependency
Date: Mon, 8 Jan 2018 14:52:38 -0800 [thread overview]
Message-ID: <20180108225238.GN9671@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180108122823.GL3668920@devbig577.frc2.facebook.com>
On Mon, Jan 08, 2018 at 04:28:23AM -0800, Tejun Heo wrote:
> Hello, Paul.
>
> Sorry about the delay. Travel followed by cold. :(
>
> On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote:
> > Actually, after taking a quick look, could you please supply me with
> > a way of mark a statically allocated workqueue as WQ_MEM_RECLAIM after
> > the fact? Otherwise, I end up having to check for the workqueue having
>
> Hmmm... there is no statically allocated workqueue tho. If you're
> referring to the system-wide workqueues (system*_wq), they're just
> created dynamically early during boot.
Good point, I was confused. But yes, they are conveniently allocated
just before the call to rcu_init(), which does work out well. ;-)
> > been allocated pretty much each time I use it, which is going to be an
> > open invitation for bugs. Plus it looks like there are ways that RCU's
> > workqueue wakeups can be executed during very early boot, which can be
> > handled, but again in a rather messy fashion.
> >
> > In contrast, given a way of mark a statically allocated workqueue
> > as WQ_MEM_RECLAIM after the fact, I simply continue initializing the
> > workqueue at early boot, and then add the WQ_MEM_RECLAIM marking some
> > arbitrarily chosen time after the scheduler has been initialized.
> >
> > The required change to workqueues looks easy, just move the body of
> > the "if (flags & WQ_MEM_RECLAIM) {" statement in __alloc_workqueue_key()
> > to a separate function, right?
>
> Ah, okay, yes, currently, workqueue init is kinda silly in that while
> it allows init of non-mem-reclaiming workqueues way before workqueue
> is actually online, it doesn't allow the same for mem-reclaiming ones.
> As you pointed out, it's just an oversight on my part as the init path
> split was done initially to accomodate early init of system
> workqueues.
>
> I'll update the code so that rescuers can be added later too; however,
> please note that while the work items may be queued, they won't be
> executed until workqueue_init() is run (the same as now) as there
> can't be worker threads anyway before that point.
Thank you! I added the following patch to allow RCU access to the
init_rescuer() function. Does that work for you, or did you have some
other arrangement in mind?
Thanx, Paul
------------------------------------------------------------------------
commit 66683a07503d71e5d5cceac72caf772e6e59c787
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Jan 8 14:27:46 2018 -0800
workqueue: Allow init_rescuer() to be invoked from other files
This commit exports init_rescuer() so that RCU can invoke it.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Lai Jiangshan <jiangshanlai@gmail.com>
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 4a54ef96aff5..31ce9343b4a9 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -433,6 +433,8 @@ __alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active,
#define create_singlethread_workqueue(name) \
alloc_ordered_workqueue("%s", __WQ_LEGACY | WQ_MEM_RECLAIM, name)
+int init_rescuer(struct workqueue_struct *wq);
+
extern void destroy_workqueue(struct workqueue_struct *wq);
struct workqueue_attrs *alloc_workqueue_attrs(gfp_t gfp_mask);
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index c86cc1ed678b..7440c61c6213 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3943,7 +3943,7 @@ static int wq_clamp_max_active(int max_active, unsigned int flags,
* Workqueues which may be used during memory reclaim should have a rescuer
* to guarantee forward progress.
*/
-static int init_rescuer(struct workqueue_struct *wq)
+int init_rescuer(struct workqueue_struct *wq)
{
struct worker *rescuer;
int ret;
next prev parent reply other threads:[~2018-01-08 22:52 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 ` Paul E. McKenney [this message]
2018-01-09 0:31 ` [PATCH] cgroup/cpuset: fix circular locking dependency 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
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=20180108225238.GN9671@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=avagin@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=prsood@codeaurora.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).