All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Prateek Sood <prsood-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	avagin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	sramana-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.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-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>

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-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
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-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
    Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
    Cc: Lai Jiangshan <jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

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;

WARNING: multiple messages have this Message-ID (diff)
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;

  parent reply	other threads:[~2018-01-08 22:52 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28  1:22 cgroup/for-next: WARNING: possible circular locking dependency detected in cpuset_write_resmask Andrei Vagin
2017-11-28 11:35 ` [PATCH] cgroup/cpuset: fix circular locking dependency Prateek Sood
     [not found]   ` <1511868946-23959-1-git-send-email-prsood-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-12-04  5:14     ` Prateek Sood
2017-12-04  5:14       ` Prateek Sood
     [not found]       ` <623f214b-8b9a-f967-7a3d-ca9c06151267-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-12-04 20:22         ` Tejun Heo
2017-12-04 20:22           ` Tejun Heo
2017-12-04 22:58           ` Tejun Heo
     [not found]             ` <20171204225825.GP2421075-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-12-04 23:01               ` Peter Zijlstra
2017-12-04 23:01                 ` Peter Zijlstra
2017-12-08  9:40                 ` Prateek Sood
     [not found]                   ` <4e63b5e9-1696-910f-16ac-4d4d7eb98725-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-12-08 11:45                     ` Prateek Sood
2017-12-08 11:45                       ` Prateek Sood
     [not found]                       ` <40968aea-cd73-5ce4-d559-962d91e315c5-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-12-11 15:32                         ` Tejun Heo
2017-12-11 15:32                           ` Tejun Heo
2017-12-13 14:28                           ` Prateek Sood
2017-12-13 15:40                             ` Tejun Heo
     [not found]                               ` <20171213154041.GP3919388-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-12-15  8:54                                 ` Prateek Sood
2017-12-15  8:54                                   ` Prateek Sood
2017-12-15 13:22                                   ` Tejun Heo
2017-12-15 19:06                                     ` Prateek Sood
     [not found]                                       ` <b50d7b64-121f-9a4c-5269-aec9a73787ba-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-12-19  7:26                                         ` [PATCH] cgroup: Fix deadlock in cpu hotplug path Prateek Sood
2017-12-19  7:26                                           ` Prateek Sood
2017-12-19 13:39                                           ` Tejun Heo
     [not found]                 ` <20171204230117.GF20227-IIpfhp3q70z/8w/KjCw3T+5/BudmfyzbbVWyRVo5IupeoWH0uzbU5w@public.gmane.org>
2017-12-11 15:20                   ` [PATCH] cgroup/cpuset: fix circular locking dependency Tejun Heo
2017-12-11 15:20                     ` Tejun Heo
     [not found]                     ` <20171211152059.GH2421075-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-12-13  7:50                       ` Prateek Sood
2017-12-13  7:50                         ` Prateek Sood
2017-12-13 16:06                         ` Tejun Heo
     [not found]                           ` <20171213160617.GQ3919388-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2017-12-15 19:04                             ` Prateek Sood
2017-12-15 19:04                               ` Prateek Sood
2017-12-28 20:37                             ` Prateek Sood
2017-12-28 20:37                               ` Prateek Sood
2018-01-02 16:16                               ` Tejun Heo
     [not found]                                 ` <20180102161656.GD3668920-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2018-01-02 17:44                                   ` Paul E. McKenney
2018-01-02 17:44                                     ` Paul E. McKenney
2018-01-02 18:01                                     ` Paul E. McKenney
     [not found]                                       ` <20180102180119.GA1355-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-01-08 12:28                                         ` Tejun Heo
2018-01-08 12:28                                           ` Tejun Heo
     [not found]                                           ` <20180108122823.GL3668920-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2018-01-08 13:47                                             ` [PATCH wq/for-4.16 1/2] workqueue: separate out init_rescuer() Tejun Heo
2018-01-08 13:47                                               ` 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 13:47                                                 ` Tejun Heo
2018-01-08 22:52                                             ` Paul E. McKenney [this message]
2018-01-08 22:52                                               ` [PATCH] cgroup/cpuset: fix circular locking dependency Paul E. McKenney
2018-01-09  0:31                                               ` Paul E. McKenney
     [not found]                                                 ` <20180109003127.GA30224-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-01-09  3:42                                                   ` Tejun Heo
2018-01-09  3:42                                                     ` Tejun Heo
2018-01-09  4:20                                                     ` Paul E. McKenney
2018-01-09 13:44                                                       ` Tejun Heo
     [not found]                                                         ` <20180109134448.GE3668920-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2018-01-09 15:21                                                           ` Paul E. McKenney
2018-01-09 15:21                                                             ` Paul E. McKenney
2018-01-09 15:37                                                             ` Tejun Heo
     [not found]                                                               ` <20180109153752.GI3668920-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2018-01-09 16:00                                                                 ` Paul E. McKenney
2018-01-09 16:00                                                                   ` Paul E. McKenney
2018-01-10 20:08                                                                   ` Paul E. McKenney
     [not found]                                                                     ` <20180110200821.GA22541-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2018-01-10 21:41                                                                       ` Tejun Heo
2018-01-10 21:41                                                                         ` Tejun Heo
     [not found]                                                                         ` <20180110214101.GE3460072-4dN5La/x3IkLX0oZNxdnEQ2O0Ztt9esIQQ4Iyu8u01E@public.gmane.org>
2018-01-10 22:10                                                                           ` Paul E. McKenney
2018-01-10 22:10                                                                             ` Paul E. McKenney
2018-01-15 12:02                                   ` Prateek Sood
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-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
    --cc=avagin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=prsood-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=sramana-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.