From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754831Ab2ALR5s (ORCPT ); Thu, 12 Jan 2012 12:57:48 -0500 Received: from mail-gx0-f174.google.com ([209.85.161.174]:38306 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751860Ab2ALR5q (ORCPT ); Thu, 12 Jan 2012 12:57:46 -0500 Date: Thu, 12 Jan 2012 09:57:25 -0800 From: Mandeep Singh Baines To: Oleg Nesterov Cc: Mandeep Singh Baines , Frederic Weisbecker , Li Zefan , Tejun Heo , LKML , Containers , Cgroups , KAMEZAWA Hiroyuki , Paul Menage , Andrew Morton , "Paul E. McKenney" Subject: Re: Q: cgroup: Questions about possible issues in cgroup locking Message-ID: <20120112175725.GD9511@google.com> References: <20111221190817.GI17668@somewhere> <20111221192413.GF13529@google.com> <20111221200422.GJ17668@somewhere> <20111222153004.GA30522@redhat.com> <20120104193614.GF9511@google.com> <20120106152356.GA23995@redhat.com> <20120106182535.GJ9511@google.com> <20120111160730.GA24556@redhat.com> <20120112003102.GB9511@google.com> <20120112170728.GA25717@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120112170728.GA25717@redhat.com> X-Operating-System: Linux/2.6.38.8-gg621 (x86_64) User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Oleg, Oleg Nesterov (oleg@redhat.com) wrote: > Hi Mandeep, > > On 01/11, Mandeep Singh Baines wrote: > > > > > > > > #define while_each_thread(g, t, o) \ > > > > while (t->group_leader == o && (t = next_thread(t)) != g) > > > > > > > > Where o should have the value of g->group_leader. > > > > > > I don't understand how this helps... and how this can work even > > > ignoring the barriers. > > > > > > OK, we have the main thream M and the sub-thread T, we are doing > > > > > > do { > > > do_something(t); > > > } while_each_thread(M, t, M); > > > > > > why we can't miss T if it does exec? > > > > > > > So for: > > > > struct task *M; /* assuming this is passed in to us */ > > struct task *L = M->group_leader; > > L == M > > > do { > > do_something(T); > > } while_each_thread(M, T, L); > > > > Here is my thinking. > > > > If some thread K does exec, you won't miss it because: > > > > 1) Ignoring the group_leader check, you'll visit K just by following > > next_thread(). That's the case today and is what you except > > when iterating over an rcu_list. > > 2) (t->group_leader == o) will fail iff t is the exec thread. > > Since we test t->group_leader before re-assigning it (t=next_thread()), > > the test will fail only after visiting the exec thread. So you'll > > visit the exec thread and then terminate the loop. > > Still can't understand... Lets look at this trivial example again. > > We start from the main thread M, it is ->group_leader. There is > another thread T in this thread group. We are doing > > OLD = M; > > t = M; > do { > do_smth(t); > } > while (t->group_leader == OLD && ((t = next_thread(t)) != M); > > The first iteration does do_smth(M). > > T calls de_thread() and, in particular, it does M->group_leader = T > (see "leader->group_leader = tsk" in de_thread). > > after that t->group_leader == OLD fails. t == M, its group_leader == T. > do_smth(T) won't be called. > > No? > I think we can handle this by removing the assignment. So in de_thread(): - leader->group_leader = tsk; tsk->exit_signal = SIGCHLD; leader->exit_signal = -1; BUG_ON(leader->exit_state != EXIT_ZOMBIE); leader->exit_state = EXIT_DEAD; In the current d_thread(), four statements after reassigning leader->group_leader, we mark the old leader as EXIT_DEAD. So what if we leave leader->group_leader = leader. Since its EXIT_DEAD a few statements later, I don't think anything should break. What do you think? Regards, Mandeep > Oleg. >