All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zefan Li <lizefan@huawei.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Mike Galbraith <umgwanakikbuti@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Stefan Bader <stefan.bader@canonical.com>
Subject: Re: [PATCH] sched, autogroup: Fix failure when writing to cpu.rt_runtime_us
Date: Sat, 7 Feb 2015 15:02:11 +0800	[thread overview]
Message-ID: <54D5B873.5030208@huawei.com> (raw)
In-Reply-To: <20150206105840.GJ23123@twins.programming.kicks-ass.net>

>> See this commit:
>>
>> commit f44937718ce3b8360f72f6c68c9481712517a867
>> Author: Mike Galbraith <efault@gmx.de>
>> Date:   Thu Jan 13 04:54:50 2011 +0100
>>
>>     sched, autogroup: Fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure
>> ...
>> +       /*
>> +        * Autogroup RT tasks are redirected to the root task group
>> 	...
>> +        * the policy change to proceed.  Thereafter, task_group()
>> +        * returns &root_task_group, ...
>> +        */
> 
> That comment is misleading; if you look at the actual code what we do is
> redirect RT programs to _run_ in the root_task_group, but their
> task_group() should still be autogroup.
> 
> Otherwise people could escape their cgroup by switching to and from a RT
> class.
> 

Before 8323f26ce342 "sched: Fix race in task_group()", task_group() of
those RT tasks always return root_task_group, but the escape can't happen.

After commit 8323f26ce342, task_group always return root_task_group except
for the case I showed:

1. Change scheduling policy before setsid():

 # cat /proc/sched_debug | grep test
 R           test  4194     24851.893077       945   120     24851.893077     11196.482331         0.000000 /

2. Change policy after setsid():

 R           test  4142      4962.517723       420   120      4962.517723      4974.126149         0.000000 /autogroup-44

I think we can fix it with:

diff --git a/kernel/sched/auto_group.c b/kernel/sched/auto_group.c
index 8a2e230..8c3a169 100644
--- a/kernel/sched/auto_group.c
+++ b/kernel/sched/auto_group.c
@@ -115,9 +115,6 @@ bool task_wants_autogroup(struct task_struct *p, struct task_group *tg)
 	if (tg != &root_task_group)
 		return false;
 
-	if (p->sched_class != &fair_sched_class)
-		return false;
-
 	/*
 	 * We can only assume the task group can't go away on us if
 	 * autogroup_move_group() can see us on ->thread_group list.

> So what I think you want is something like the below; preferably with a
> comment on ;-)
> 

This is exactly what I did at first, but besides the issue described above,
seems it might lead to starving RT tasks.

If there's some rt task in autogroups but none in root cgroup, it's allowed
to set rt_runtime to 0, so I think we have to disallow this setting, like what
we already do with global rt_runtime.

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 89e7283..3f6c3ad 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7460,6 +7460,9 @@ static inline int tg_has_rt_tasks(struct task_group *tg)
 {
 	struct task_struct *g, *p;
 
+	if (task_group_is_autogroup(tg))
+		return 0;
+
 	for_each_process_thread(g, p) {
 		if (rt_task(p) && task_group(p) == tg)
 			return 1;
@@ -7540,6 +7543,9 @@ static int __rt_schedulable(struct task_group *tg, u64 period, u64 runtime)
 		.rt_runtime = runtime,
 	};
 
+	if (tg == &root_task_group && runtime == 0)
+		return -EINVAL;
+
 	rcu_read_lock();
 	ret = walk_tg_tree(tg_rt_schedulable, tg_nop, &data);
 	rcu_read_unlock();

> ---
>  kernel/sched/core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 1f37fe7f77a4..f4fd048ce7cf 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7644,6 +7644,9 @@ static inline int tg_has_rt_tasks(struct task_group *tg)
>  {
>  	struct task_struct *g, *p;
>  
> +	if (task_group_is_autogroup(tg))
> +		return 0;
> +
>  	for_each_process_thread(g, p) {
>  		if (rt_task(p) && task_group(p) == tg)
>  			return 1;
> .
> 


  reply	other threads:[~2015-02-07  7:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05  8:33 [PATCH] sched, autogroup: Fix failure when writing to cpu.rt_runtime_us Zefan Li
2015-02-05 14:25 ` Peter Zijlstra
2015-02-06  1:30   ` Zefan Li
2015-02-06 10:58     ` Peter Zijlstra
2015-02-07  7:02       ` Zefan Li [this message]
2015-02-09 11:22         ` Peter Zijlstra
2015-02-09 11:27           ` Peter Zijlstra
2015-02-18 17:09             ` [tip:sched/core] sched/rt: Avoid obvious configuration fail tip-bot for Peter Zijlstra
2015-02-10  1:26           ` [PATCH] sched, autogroup: Fix failure when writing to cpu.rt_runtime_us Zefan Li
2015-02-18 17:09           ` [tip:sched/core] sched/autogroup: Fix failure to set cpu.rt_runtime_us tip-bot for Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54D5B873.5030208@huawei.com \
    --to=lizefan@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stefan.bader@canonical.com \
    --cc=umgwanakikbuti@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.