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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Thu, 20 Jan 2011 05:59:28 +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 12:18 +0800, Yong Zhang wrote:
> On Wed, Jan 19, 2011 at 9:30 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > +static void switched_from_fair(struct rq *rq, struct task_struct *p)
> > +{
> > +       struct sched_entity *se = &p->se;
> > +       struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > +
> > +       /*
> > +        * Ensure the task's vruntime is normalized, so that when its
> > +        * switched back to the fair class the enqueue_entity(.flags=0) will
> > +        * do the right thing.
> > +        *
> > +        * If it was on_rq, then the dequeue_entity(.flags=0) will already
> > +        * have normalized the vruntime, if it was !on_rq, then only when
> > +        * the task is sleeping will it still have non-normalized vruntime.
> > +        */
> > +       if (!se->on_rq && p->state != TASK_RUNNING)
> > +               se->vruntime -= cfs_rq->min_vruntime;
> 
> Here it's possible that se->vruntime is little than cfs_rq->min_vruntime.

The idea of normalizing is to preserve the offset, so the task can be
enqueued at this same offset, regardless of movement.

For sleepers, we can't usually do this until enqueue time, lest their
sleep time be unaccountable.  Here, we have to normalize, so the task's
sleep stops from the vantage point of fair_class upon class exit, and
either resumes where it left off upon re-entry, or the task is enqueued
at it's last offset as usual for runnable tasks.

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