Re: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1)

[Steven Rostedt]

On Thu, 22 Jun 2006, Thomas Gleixner wrote:

> On Thu, 2006-06-22 at 09:45 -0400, Steven Rostedt wrote:
> > > + * Recheck the pi chain, in case we got a priority setting
> > > + *
> > > + * Called from sched_setscheduler
> > > + */
> > > +void rt_mutex_adjust_pi(struct task_struct *task)
> > > +{
> > > +	struct rt_mutex_waiter *waiter = task->pi_blocked_on;
> > > +	unsigned long flags;
> >
> > Hmm, what if the process wakes up here and unblocks?  Since waiter is
> > on the stack, you could have a nasty race here.
>
> Thats fixed already. Moved into te pi_lock section

Yeah I saw that.

>
> > > +
> > > +	spin_lock_irqsave(&task->pi_lock, flags);
> > > +
> > > +	if (!waiter || waiter->list_entry.prio == task->prio) {
> > > +		spin_unlock_irqrestore(&task->pi_lock, flags);
> > > +		return;
> > > +	}
> > > +
> > > +	get_task_struct(task);
> > > +	spin_unlock_irqrestore(&task->pi_lock, flags);
> > > +
> > > +	rt_mutex_adjust_prio_chain(task, 0, NULL, NULL, task);
> >
> > Nasty nasty nasty!
>
> What's nasty ?
>

The fact that sched_setscheduler can never be called by interrupt context.
So I don't know how you're going to handle the high_res dynamic priority
now.

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/