Messages in this thread | | | Date | Thu, 22 Jun 2006 09:45:24 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: Why can't I set the priority of softirq-hrt? (Re: 2.6.17-rt1) |
| |
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/
| |