Subject: Re: [PATCH] sched: Don't allow priority switch to realtime when
 the task doesn't belong to init_task_group and when CONFIG_RT_GROUP_SCHED
 isn't set
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: bharata@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org,
       Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
       Ingo Molnar <mingo@elte.hu>, Dhaval Giani <dhaval@linux.vnet.ibm.com>
In-Reply-To: <20081120061854.GA4349@in.ibm.com>
References: <20081120061854.GA4349@in.ibm.com>
Content-Type: text/plain
Date: Sun, 23 Nov 2008 02:11:16 +0100
Message-Id: <1227402676.7685.19942.camel@twins>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1362
Lines: 32

On Thu, 2008-11-20 at 11:48 +0530, Bharata B Rao wrote:
> Applies on 2.6.28-rc5.
> 
> With CONFIG_RT_GROUP_SCHED not set, don't allow a task's priority switch
> to realtime if the task isn't part of init_task_group.
> 
> A task belonging to a fair group could use sched_setscheduler/sched_setparam
> to become a realtime task. If such a task belongs to one of the
> child groups of init_task_group and if CONFIG_RT_GROUP_SCHED is not set,
> then it ends up getting queued in init_task_group's runqueue.
> So we have a situation where, a task belongs to one group (child)
> but ends in the runqueue of another group (init_task_group).
> This does not look correct.
> 
> Fix this by failing such priority change requests in sched_setscheduler()
> and sched_setparam().

NAK

!RT_GROUP means the RT tasks should be fully invariant to any grouping
configuration. This patch breaks that.

Furthermore your justification for this is plain wrong, you write as if
an RT tasks can belong to any grouping (in the !RT_GROUP case), by the
above this is untrue and shows a fundamental mis-understanding of the
concepts involved.

--
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/