[lkml]   [2002]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: lock order in O(1) scheduler
On Thu, 2002-01-10 at 00:10, wrote:

> I was unable to figure out what the logic of the '(smp_processor_id() <
> p->cpu)' test is.. (Why should the CPU number of the process being awoken
> matter?) My best guess is that this is to enforce a locking invariant -
> but if so, isn't this test backwards? If p->cpu > current->cpu then
> p->cpu's runqueue is locked first followed by this_rq - locking greatest to
> least, where the rest of the code does least to greatest..

Not so sure of the validity, but it is to respect lock order. Locking
order is to obtain the locks lowest CPU id first to prevent AB/BA
deadlock. See the comment above the runqueue data structure for

> Also, this code in set_cpus_allowed() looks bogus:
> if (target_cpu < smp_processor_id()) {
> spin_lock_irq(&target_rq->lock);
> spin_lock(&this_rq->lock);
> } else {
> spin_lock_irq(&target_rq->lock);
> spin_lock(&this_rq->lock);
> }

This is certainly wrong, I noticed this earlier today. The unlocking
order is not respected either, I suspect.

I believe the code should be:

if (target_cpu < smp_processor_id()) {
} else {

Not so sure about unlocking. Ingo?

Robert Love

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:18    [W:0.058 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site