On Fri, 28 Feb 2014, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > This is a note to let you know that I've just added the patch titled > > cgroup: use an ordered workqueue for cgroup destruction > > to the 3.10-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary > > The filename of the patch is: > cgroup-use-an-ordered-workqueue-for-cgroup-destruction.patch > and it can be found in the queue-3.10 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable@xxxxxxxxxxxxxxx> know about it. Greg, please remove this commit from all your trees: we later found it to be inadequate, and Tejun reverted it from his tree in 1a11533fbd71 Revert "cgroup: use an ordered workqueue for cgroup destruction". There's a replacement fix (to mm/memcontrol.c) from Filipe currently in akpm's mmotm, and expected to go through to Linus shortly; after which it will percolate through to you and to stable (but even then we shall have to supply you with a modified version for each stable release - although the 3.14 commit looks good, that's deceptive, and we need to adjust it slightly for the backports; don't worry, nothing you need remember, Filipe or I will take care of that once you announce his patch going into your stable trees). Sorry for all the noise, Hugh > > > From ab3f5faa6255a0eb4f832675507d9e295ca7e9ba Mon Sep 17 00:00:00 2001 > From: Hugh Dickins <hughd@xxxxxxxxxx> > Date: Thu, 6 Feb 2014 15:56:01 -0800 > Subject: cgroup: use an ordered workqueue for cgroup destruction > > From: Hugh Dickins <hughd@xxxxxxxxxx> > > commit ab3f5faa6255a0eb4f832675507d9e295ca7e9ba upstream. > > Sometimes the cleanup after memcg hierarchy testing gets stuck in > mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. > > There may turn out to be several causes, but a major cause is this: the > workitem to offline parent can get run before workitem to offline child; > parent's mem_cgroup_reparent_charges() circles around waiting for the > child's pages to be reparented to its lrus, but it's holding cgroup_mutex > which prevents the child from reaching its mem_cgroup_reparent_charges(). > > Just use an ordered workqueue for cgroup_destroy_wq. > > tj: Committing as the temporary fix until the reverse dependency can > be removed from memcg. Comment updated accordingly. > > Fixes: e5fca243abae ("cgroup: use a dedicated workqueue for cgroup destruction") > Suggested-by: Filipe Brandenburger <filbranden@xxxxxxxxxx> > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > Signed-off-by: Tejun Heo <tj@xxxxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > > --- > kernel/cgroup.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -4699,12 +4699,16 @@ static int __init cgroup_wq_init(void) > /* > * There isn't much point in executing destruction path in > * parallel. Good chunk is serialized with cgroup_mutex anyway. > - * Use 1 for @max_active. > + * > + * XXX: Must be ordered to make sure parent is offlined after > + * children. The ordering requirement is for memcg where a > + * parent's offline may wait for a child's leading to deadlock. In > + * the long term, this should be fixed from memcg side. > * > * We would prefer to do this in cgroup_init() above, but that > * is called before init_workqueues(): so leave this until after. > */ > - cgroup_destroy_wq = alloc_workqueue("cgroup_destroy", 0, 1); > + cgroup_destroy_wq = alloc_ordered_workqueue("cgroup_destroy", 0); > BUG_ON(!cgroup_destroy_wq); > return 0; > } > > > Patches currently in stable-queue which might be from hughd@xxxxxxxxxx are > > queue-3.10/cgroup-use-an-ordered-workqueue-for-cgroup-destruction.patch > queue-3.10/memcg-fix-endless-loop-caused-by-mem_cgroup_iter.patch > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html