Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756323AbdLONWi (ORCPT ); Fri, 15 Dec 2017 08:22:38 -0500 Received: from mail-qt0-f196.google.com ([209.85.216.196]:33398 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756276AbdLONWZ (ORCPT ); Fri, 15 Dec 2017 08:22:25 -0500 X-Google-Smtp-Source: ACJfBousSaPDlfJtQuWrPswgAZo/qadNHi35vaCEJwjuQJePW1p9On9L71GV9MxXvgfIMt1cNSeljA== Date: Fri, 15 Dec 2017 05:22:22 -0800 From: Tejun Heo To: Prateek Sood Cc: Peter Zijlstra , 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 Message-ID: <20171215132222.GF3919388@devbig577.frc2.facebook.com> References: <623f214b-8b9a-f967-7a3d-ca9c06151267@codeaurora.org> <20171204202219.GF2421075@devbig577.frc2.facebook.com> <20171204225825.GP2421075@devbig577.frc2.facebook.com> <20171204230117.GF20227@worktop.programming.kicks-ass.net> <4e63b5e9-1696-910f-16ac-4d4d7eb98725@codeaurora.org> <40968aea-cd73-5ce4-d559-962d91e315c5@codeaurora.org> <20171211153258.GI2421075@devbig577.frc2.facebook.com> <20171213154041.GP3919388@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1047 Lines: 30 Hello, Prateek. On Fri, Dec 15, 2017 at 02:24:55PM +0530, Prateek Sood wrote: > Following are two ways to improve cgroup_transfer_tasks(). In > both cases task in PF_EXITING state would be left in source > cgroup. It would be removed from cgroup_exit() in exit path. > > diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c > index 024085d..e2bdcdb 100644 > --- a/kernel/cgroup/cgroup-v1.c > +++ b/kernel/cgroup/cgroup-v1.c > @@ -123,7 +123,10 @@ int cgroup_transfer_tasks(struct cgroup *to, struct cgroup *from) > */ > do { > css_task_iter_start(&from->self, 0, &it); > - task = css_task_iter_next(&it); > + do { > + task = css_task_iter_next(&it); > + } while (task && (task & PF_EXITING)) > + Yeah, this looks good to me. We can't just make a single pass as in the other one because we can race aginst fork. And PF_EXITING being left behind is what was happening previously too anyway. They can't be moved. Thanks. -- tejun