linux-kernel - Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases

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:	Mon, 20 Apr 2015 19:20:48 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Xunlei Pang <xlpang@....com>, linux-kernel@...r.kernel.org,
	Juri Lelli <juri.lelli@...il.com>,
	Xunlei Pang <pang.xunlei@...aro.org>
Subject: Re: [PATCH v6 2/3] sched/rt: Fix wrong SMP scheduler behavior for
 equal prio cases

On Mon, Apr 20, 2015 at 10:52:28AM -0400, Steven Rostedt wrote:
> On Mon, 20 Apr 2015 16:22:47 +0800
> Xunlei Pang <xlpang@....com> wrote:
> 
> >  static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
> >  {
> >  }
> > @@ -1506,8 +1526,21 @@ static void put_prev_task_rt(struct rq *rq, struct task_struct *p)
> >  	 * The previous task needs to be made eligible for pushing
> >  	 * if it is still active
> >  	 */
> > -	if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1)
> > -		enqueue_pushable_task(rq, p);
> > +	if (on_rt_rq(&p->rt) && p->nr_cpus_allowed > 1) {
> > +		/*
> > +		 * put_prev_task_rt() is called by many functions,
> > +		 * pick_next_task_rt() is the only one may have
> > +		 * PREEMPT_ACTIVE set. So if detecting p(current
> > +		 * task) is preempted in such case, we should
> > +		 * enqueue it to the front of the pushable plist,
> > +		 * as there may be multiple tasks with the same
> > +		 * priority as p.
> 
> The above comment is very difficult to understand. Maybe something like:
> 
> 		/*
> 		 * When put_prev_task_rt() is called by
> 		 * pick_next_task_rt(), if PREEMPT_ACTIVE is set, it
> 		 * means that the current rt task is being preempted by
> 		 * a higher priority task. To maintain FIFO, it must
> 		 * stay ahead of any other task that is queued at the
> 		 * same priority.
> 		 */
> 
> -- Steve
> 
> > +		 */
> > +		if (preempt_count() & PREEMPT_ACTIVE)
> > +			enqueue_pushable_task_preempted(rq, p);
> > +		else
> > +			enqueue_pushable_task(rq, p);
> > +	}
> >  }

This looks wrong, what do you want to find? _any_ preemption? In that
case PREEMPT_ACTIVE is wrong. What you need to check is if the task is
still on the RQ or not.

If the task was put to sleep it got dequeued, if it was not dequeued, it
got preempted.

PREEMPT_ACTIVE is only ever set for forced kernel preemption, which is a
special sub case only ever triggered with CONFIG_PREEMPT=y.
--
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/