Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753767Ab0KPPmM (ORCPT ); Tue, 16 Nov 2010 10:42:12 -0500 Received: from mailout-de.gmx.net ([213.165.64.22]:53311 "HELO mail.gmx.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP id S1752349Ab0KPPmL (ORCPT ); Tue, 16 Nov 2010 10:42:11 -0500 X-Authenticated: #14349625 X-Provags-ID: V01U2FsdGVkX192+t1Qb352qmPMykrU2sfep8qhjvCLxAnvH/P5wF MCr6hex/XEviEa Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups From: Mike Galbraith To: Oleg Nesterov Cc: Peter Zijlstra , Linus Torvalds , Markus Trippelsdorf , Mathieu Desnoyers , Ingo Molnar , LKML In-Reply-To: <20101116150319.GA3475@redhat.com> References: <1289783580.495.58.camel@maggy.simson.net> <1289811438.2109.474.camel@laptop> <1289820766.16406.45.camel@maggy.simson.net> <1289821590.16406.47.camel@maggy.simson.net> <20101115125716.GA22422@redhat.com> <1289856350.14719.135.camel@maggy.simson.net> <20101116130413.GA29368@redhat.com> <1289917109.5169.131.camel@maggy.simson.net> <20101116150319.GA3475@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 16 Nov 2010 08:41:48 -0700 Message-ID: <1289922108.5169.185.camel@maggy.simson.net> Mime-Version: 1.0 X-Mailer: Evolution 2.30.1.2 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1378 Lines: 42 On Tue, 2010-11-16 at 16:03 +0100, Oleg Nesterov wrote: > On 11/16, Mike Galbraith wrote: > > > > On Tue, 2010-11-16 at 14:04 +0100, Oleg Nesterov wrote: > > > However, I must admit I dislike this check. Because, looking at this > > > code, it is not clear why do we check PF_EXITING. It looks as if it > > > is needed for correctness. > > > > Is _not_ needed I presume. > > > > I'll remove it, I'm not overly attached (a t t a..;) to it. > > Argh! > > I was wrong, it _is_ needed for correctness. Yes, it is always safe > to read the pointer, but > > > > Yes, sure, rq->lock should ensure signal->autogroup can't go away. > > > (even if it can be changed under us). And it does, we are moving all > > > threads before kref_put(). > > > > (yeah) > > Exactly. And this means we can _only_ assume it can't go away if > autogroup_move_group() can see us on ->thread_group list. Aha! > Perhaps this deserve a commen (unless I missed something again). > > Mike, sorry for confusion. Oh no, thank you. I hadn't figured it out yet, was going to go back and poke rt kernel with sharp sticks. (exit can be one scary beast) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/