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

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 21 Jun 2006, Thomas Gleixner wrote:

> On Wed, 2006-06-21 at 16:43 +0100, Esben Nielsen wrote:
> > What about the patch below. It compiles and my UP labtop runs fine, but I
> > haven't otherwise tested it.  My labtop runs RTExec without hichups
> > until now.
>
> NAK, it puts the burden into the lock path and also does a remove / add
> which results in walking the chain twice.

I think the burden is OK.  It only happens when the process is actually
blocked, so it's the slow path anyways.

>
>  /*
> + * 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.

> +
> +	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!

> +}
> +

-- Steve

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