linux-kernel - Re: [RT] rt priority losing

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, 24 Jul 2006 12:37:22 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Esben Nielsen <nielsen.esben@...glemail.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	"Duetsch, Thomas LDE1" <thomas.duetsch@...mens.com>
Subject: Re: [RT] rt priority losing

On Mon, 2006-07-24 at 18:00 +0100, Esben Nielsen wrote:
> On Mon, 24 Jul 2006, Steven Rostedt wrote:
> 
> > Ingo or Tglx,
> >
> > It has come to my attention that the dynamic hrtimer softirq can lose a
> > boosted priority.  That is, if a softirq is running while a timeout
> > happens, and the call back is of lower priority than the currently
> > running hrtimer softirq, the timer interrupt will still lower the
> > hrtimer softirq.
> >
> > Here's the problem code:
> >
> > static void wakeup_softirqd_prio(int softirq, int prio)
> > {
> > 	/* Interrupts are disabled: no need to stop preemption */
> > 	struct task_struct *tsk = __get_cpu_var(ksoftirqd[softirq].tsk);
> >
> > 	if (tsk) {
> > 		if (tsk->normal_prio != prio) {
> > 			struct sched_param param;
> >
> > 			param.sched_priority = MAX_RT_PRIO-1 - prio;
> > 			setscheduler(tsk, -1, SCHED_FIFO, &param);
> > 		}
> > 		if(tsk->state != TASK_RUNNING)
> > 			wake_up_process(tsk);
> > 	}
> > }
> >
> >
> > So, tsk could be softirqd-hrmono and we lower the priority. (only
> > normal_prio is checked versus prio).
> >
> > So this can be a problem, if the softirq function holds a lock of a high
> > priority task, and is running boosted.  If another timer goes off with a
> > lower priority, we can lower the priority of the softirqd and lose the
> > inherited priority that it was running at.
> 
> There is a check for that inside setscheduler():
>  	p->prio = rt_mutex_getprio(p);

OK, you are right about this.  The PI chain should not be affected.  But
this could still be a problem if the softirq was running at a high prio
for a task when a lower prio callback needs to be made.  It looks like
timer is removed from the base before the function runs.  So when the
interrupt looks at the base to determine the priority to set it at, it
might actually lower the priority of a running hrtimer thread.

-- Steve


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