linux-kernel - Re: [Question] sched/rt_mutex: re-enqueue_task on rt_mutex

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]

Message-ID: <1341710959.2783.2.camel@acer.local.home>
Date:	Sat, 07 Jul 2012 21:29:19 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Question] sched/rt_mutex: re-enqueue_task on
 rt_mutex_setprio()

On Sat, 2012-07-07 at 14:44 +0900, Namhyung Kim wrote:
> Hi,
> 
> I have a question on the code below:
> 
> void rt_mutex_setprio(struct task_struct *p, int prio)
> {
>         ...
> 	if (on_rq)
> 		enqueue_task(rq, p, oldprio < prio ? ENQUEUE_HEAD : 0);
> 
> When enqueueing @p with new @prio, it seems put @p at the head of a
> rq if appropriate. I guess it's the case of boosting @p with higher
> priority, right?

Actually, no. We put @p at the head of the queue when unboosting. If a
task is going from a high priority into a lower priority, it is still
treated as "important" for that priority, and is put to the front of the
queue (it was just higher than everything else on that queue). But if we
are boosting a task from a low priority, why put it to the head of other
tasks of its new priority, when those tasks were just higher than this
task, and this task is now just an "equal".

-- Steve

>  So Should the conditional be a reverse form (provided
> that less number means higher priority)? Please shed some light on me.
> 
> Thanks,
> Namhyung


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