Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754469AbYKTH6s (ORCPT ); Thu, 20 Nov 2008 02:58:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753613AbYKTH6k (ORCPT ); Thu, 20 Nov 2008 02:58:40 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:41889 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753149AbYKTH6j (ORCPT ); Thu, 20 Nov 2008 02:58:39 -0500 Date: Thu, 20 Nov 2008 08:58:29 +0100 From: Ingo Molnar To: Bharata B Rao Cc: linux-kernel@vger.kernel.org, Srivatsa Vaddagiri , Peter Zijlstra , Dhaval Giani 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 Message-ID: <20081120075829.GA21785@elte.hu> References: <20081120061854.GA4349@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081120061854.GA4349@in.ibm.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00,DNS_FROM_SECURITYSAGE autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 DNS_FROM_SECURITYSAGE RBL: Envelope sender in blackholes.securitysage.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2116 Lines: 56 * 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(). > > Signed-off-by: Bharata B Rao > --- > kernel/sched.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > --- a/kernel/sched.c > +++ b/kernel/sched.c > @@ -5206,6 +5206,13 @@ recheck: > if (rt_bandwidth_enabled() && rt_policy(policy) && > task_group(p)->rt_bandwidth.rt_runtime == 0) > return -EPERM; > +#elif defined(CONFIG_FAIR_GROUP_SCHED) > + /* > + * If the task doesn't belong to init_task_group, don't > + * allow priority switch to realtime. (!CONFIG_RT_GROUP_SCHED) > + */ > + if (rt_policy(policy) && (task_group(p) != &init_task_group)) > + return -EPERM; > #endif > > retval = security_task_setscheduler(p, policy, param); hm, another option would be, instead of denying something (which denial might not even be noticed by the app) that the app clearly has enough privilege to request - to just act upon it and move the task to the init_task_group? the app cannot expect fair scheduling for this task anyway. And if we want to forbid tasks from doing so - do not give them privilege to go to RT priorities. Ingo -- 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/