linux-kernel - Re: Bug in scheduler when using rt

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 20 Jan 2011 11:07:27 +0100
From:	Mike Galbraith <efault@....de>
To:	Yong Zhang <yong.zhang0@...il.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, samu.p.onkalo@...ia.com,
	mingo@...e.hu,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	tglx <tglx@...utronix.de>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Bug in scheduler when using rt_mutex

On Thu, 2011-01-20 at 17:07 +0800, Yong Zhang wrote:
> On Thu, Jan 20, 2011 at 4:37 PM, Mike Galbraith <efault@....de> wrote:
> > On Thu, 2011-01-20 at 15:06 +0800, Yong Zhang wrote:
> >> On Thu, Jan 20, 2011 at 2:12 PM, Mike Galbraith <efault@....de> wrote:
> >> > If the task returns as a sleeper, place entity() will be called when it
> >> > is awakened, so it's sleep credit will be clipped as usual.  So vruntime
> >> > can be much less than min_vruntime at class exit time, and it doesn't
> >> > matter, clipping on wakeup after re-entry takes care of it.. if that's
> >> > what you were thinking about.
> >>
> >> For a sleep task which stay in sched_fair before it's waked:
> >> try_to_wake_up()
> >>   ttwu_activate()
> >>     activate_task()
> >>       enqueue_task_fair()
> >>         enqueue_entity()
> >>           place_entity()        <== clip vruntime
> >>
> >> For a sleep task which promote to sched_rt when it's sleep:
> >> rt_mutex_setprio()
> >>   check_class_changed()
> >>     switch_from_fair()       <== vruntime -= min_vruntime
> >>       try_to_wake_up()
> >>         ...run then stay on rq
> >>         rt_mutex_setprio()
> >>           enqueue_task_fair()     <==vruntime += min_vruntime
> >>
> >> The difference is that in the second case, place_entity() is not
> >> called, but wrt sched_fair, the task is a WAKEUP task.
> >> Then we place this task in sched_fair before where it should be.
> >
> > D'oh.  You're right, he needs to be clipped before he leaves.
> 
> Exactly we should clip it when it comes back, because it still could
> sleep for some time after it leaves ;)

That's ok, we don't and aren't supposed to care what happens while he's
gone.  But we do have to make sure that vruntime is sane either when he
leaves, or when he comes back.  Seems to me the easiest is clip when he
leaves to cover him having slept a long time before leaving, then coming
back on us as a runner.  If he comes back as a sleeper, he'll be clipped
again anyway, so all is well.

sched_fork() should probably zero child's vruntime too, so non-fair
children can't enter fair_class with some bogus lag they never had.

	-Mike

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