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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
