linux-kernel - Re: [PATCH v3] sched/deadline: overrun could happen in start_hrtick

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]

Date:	Tue, 12 Aug 2014 16:52:54 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"xiaofeng.yan" <xiaofeng.yan@...wei.com>
Cc:	mingo@...hat.com, peterz@...radead.org, juri.lelli@...il.com,
	linux-kernel@...r.kernel.org, xiaofeng.yan2012@...il.com
Subject: Re: [PATCH v3] sched/deadline: overrun could happen in
 start_hrtick_dl


* xiaofeng.yan <xiaofeng.yan@...wei.com> wrote:

> It could be wrong for the precision of runtime and deadline
> when the precision is within microsecond level. For example:
> Task runtime deadline period
>  P1   200us   500us   500us
> 
> This case need enbale HRTICK feature by the next command
>
> PC#echo "HRTICK" > /sys/kernel/debug/sched_features
> PC#trace-cmd record -e sched_switch &
> PC#./schedtool -E -t 200000:500000 -e ./test
> 
> Some of runtime and deadline run with millisecond level by
> reading kernershark. Some pieces of trace.dat are as follows:
> (remove some irrelevant information)
> <idle>-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
> test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
> <idle>-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
> test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
> trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test
> 
> We can get the runtime from the information at some point.
> runtime = 157.605657 - 157.608183
> runtime = 0.002526(2.526ms)
> The correct runtime should be less than or equal to 200us at some point.
> 
> The problem is caused by a conditional judgment "delta > 10000".
> Because no hrtimer start up to control the runtime when runtime is less than 10us.
> So the process will continue to run until tick-period coming.
> 
> Move the code with the limit of the least time slice
> from hrtick_start_fair() to hrtick_start() because
> EDF schedule class also need this function in start_hrtick_dl().
> 
> To fix this problem, we call hrtimer_start() unconditionally in start_hrtick_dl(),
> and make sure schedule slice won't be smaller than 10us in hrtimer_start().
> 
> Signed-off-by: Xiaofeng Yan <xiaofeng.yan@...wei.com>
> Reviewed-by:   Peter Zijlstra <peterz@...radead.org>
> Reviewed-by:   Li Zefan <lizefan@...wei.com>

The whole changelog is very hard to read and isn't proper English, nor 
is it truly explanatory. Could you please fix the changelog, or bounce 
it to someone who will fix it for you?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/