Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759119Ab0KPBzk (ORCPT ); Mon, 15 Nov 2010 20:55:40 -0500 Received: from smtp-out.google.com ([216.239.44.51]:33602 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754962Ab0KPBzi convert rfc822-to-8bit (ORCPT ); Mon, 15 Nov 2010 20:55:38 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=pht408iJasN0taGS6Zd8OvPV4t9iDxESL+IVwkwGW5k8Yi8p7+qXGHxJQYJqysIzYz HdnTa3J9TuJ+o4lDlfAA== MIME-Version: 1.0 In-Reply-To: References: <1287479765.9920.9.camel@marge.simson.net> <1287487757.24189.40.camel@marge.simson.net> <1287511983.7417.45.camel@marge.simson.net> <1287514410.7368.10.camel@marge.simson.net> <20101020025652.GB26822@elte.hu> <1287648715.9021.20.camel@marge.simson.net> <20101021105114.GA10216@Krystal> <1287660312.3488.103.camel@twins> <20101021162924.GA3225@redhat.com> <1288076838.11930.1.camel@marge.simson.net> <1288078144.7478.9.camel@marge.simson.net> <1289489200.11397.21.camel@maggy.simson.net> <30291.1289860866@localhost> <1289864780.14719.172.camel@maggy.simson.net> <1289865870.14719.185.camel@maggy.simson.net> From: Paul Menage Date: Mon, 15 Nov 2010 17:55:13 -0800 Message-ID: Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups To: Linus Torvalds Cc: Mike Galbraith , Valdis.Kletnieks@vt.edu, Oleg Nesterov , Peter Zijlstra , Mathieu Desnoyers , Ingo Molnar , LKML , Markus Trippelsdorf , Daniel Lezcano Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 953 Lines: 24 On Mon, Nov 15, 2010 at 5:18 PM, Linus Torvalds wrote: > > so sched_debug_show() is apparently calling cgroup_path() with a NULL > cgroup. I think it's "print_task()" that is to blame, it does > > ? ? cgroup_path(task_group(p)->css.cgroup, .. > > without checking whether there _is_ any css.cgroup. Right - previously the returned task_group would be always associated with a cgroup. Now, it may not be. The original task_group() should be made accessible for anything that wants a real cgroup in the scheduler hierarchy, and called from the new task_group() function. Not sure what the best naming convention would be, maybe task_group() and effective_task_group() ? Paul -- 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/