linux-kernel - Re: behavior of hrtimers scheduled to expire in the past, SCHED

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-next>] [day] [month] [year] [list]

Message-ID: <4b6fba110810221805m70fd7e72rd66da9eba8f9f532@mail.gmail.com>
Date:	Wed, 22 Oct 2008 21:05:07 -0400
From:	"Daniel Rosenthal" <danielrosenthal@....org>
To:	"Thomas Gleixner" <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>, "Ingo Molnar" <mingo@...e.hu>,
	"Dario Faggioli" <raistlin@...ux.it>,
	"Peter Zijlstra" <peterz@...radead.org>
Subject: Re: behavior of hrtimers scheduled to expire in the past, SCHED_SPORADIC subtlety

On Tue, Oct 21, 2008 at 4:09 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Mon, 20 Oct 2008, Daniel Rosenthal wrote:
>> What is the intended behavior for an hrtimer that is scheduled to
>> expire in the past?  I assumed that it would simply be scheduled to
>> expire at the nearest available time in the future, but I wrote some
>> scheduler code and it looks like hrtimers don't go off at all if they
>> are not scheduled to go off at a time which is after rq->clock.  Is
>> this the intended behavior or is this a bug?
>
> That depends on the callback mode of the hrtimer. The standard ones
> are scheduled to the softirq when they are already expired, but those
> which are not allowed to run their callback in softirq context are
> _not_ enqueued and the caller has to check, whether the timer is
> active/enqueued after starting it.

Ok, thanks for the heads up.  Is this documented somewhere, or do I
need to submit a patch?

Darrio,
Just to warn you, be careful that your SCHED_SPORADIC implementation
deals with the above situation correctly.  There are situations in
which the actual scheduling of a replenishment can unintentionally be
deferred for an excessive period of time (i.e. a SCHED_SPORADIC task
running at its high priority gets preempted for a relatively long
time, or at least a time which is long compared to the task's period).
 In this case, you may accidentally end up scheduling a replenishment
timer with an expiration time in the past (because (activation_time +
period) < rq->clock ).  Be careful to avoid this in your code because
this is subtle and it took me a very long time to debug this (this was
compounded by the fact that I made an incorrect assumption about
hrtimers, discussed above).  It can be solved by executing such past
replenishments immediately, rather than submitting them to
hrtimer_start().

And regarding SCHED_SPORADIC, I am also working on SCHED_SPORADIC in
2.6.25. If I don't finish my RFC patch by the time you finish your
final 2.6.27 patch, please let me know because I believe it would be
beneficial for us to compare code before any final decisions are made
(mine still isn't working well enough to compare yet).

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