linux-kernel - Re: [BUGFIX][PATCH] Fix sched rt group scheduling when hierachy is enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTi=9nivjLwxACYJUNS6nC0zqOo-EVZbh3am+Cs4C@mail.gmail.com>
Date:	Tue, 8 Mar 2011 16:42:00 +0800
From:	Yong Zhang <yong.zhang0@...il.com>
To:	balbir@...ux.vnet.ibm.com
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <pzijlstr@...hat.com>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Bharata B Rao <bharata.rao@...ibm.com>
Subject: Re: [BUGFIX][PATCH] Fix sched rt group scheduling when hierachy is enabled

On Mon, Mar 7, 2011 at 3:00 PM, Yong Zhang <yong.zhang0@...il.com> wrote:
>
> I have tested with the attached(web mail will mangle it) patch with
> yours applied. But I failed to trigger that WARNING.
>
> Below is my steps:
> 1)mount -t cgroup -ocpu cpu /mnt
> 2)mkdir /mnt/test-1
> 3)mkdir /mnt/test-1-1
> 4)set rt_runtime to 100000 for test-1 and test-1-1
> 5)run a loop task and attach it to test-1-1
>
> So I thought out a scenario to satisfy your description,
> but it's based on the unpatched(without your patch) kernel:
> Let's assume a dual-core system with test-1/test-1-1
> for rt group, a loop task is running on CPU 1 and test-1
> and test-1-1 are both throttled.
>
>              CPU-0                                  CPU-1
> do_sched_rt_period_timer(test-1-1)
> {
>  for CPU-1
>    unthrottled test-1-1.rt_rq[1];
>      but fail to enqueue it because
>      we alway get test-1-1.rt_se[0]
>      due to smp_processor_id();
>      thus test-1.rt_rq[1].nr_running == 0;
>      and it returned with run_time == 0;
> }
> do_sched_rt_period_timer(test-1)
>  unthrottle test-1.rt_rt[1] but
>  fail to enqueue test-1.rt_rt[1];
>  because nr_running == 0;
>
>                           So if we have your patch for issue-1, when
>                           the hrtimer is running on CPU-1, test-1-1
>                           and test-1 will be queued because that
>                           additional check in run_timer == 0 case.
>
> But once we have your patch for issue-2, the above
> problem will be killed by it. right?

And another finding is that the top rt_rq could trigger your
additional code, but we don't need to enqueue
root_task_group.rt_se[].

BTW, I update my patch(attached) to void testing on top rt_rq.

Thanks,
Yong


-- 
Only stand for myself

View attachment "0001-updated.patch" of type "text/x-patch" (597 bytes)