lkml.org 
[lkml]   [2002]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: lock order in O(1) scheduler
From
Date
On Thu, 2002-01-10 at 00:10, kevin@koconnor.net 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
explanation.

> 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()) {
spin_lock_irq(&target_rq->lock);
spin_lock(&this_rq->lock);
} else {
spin_lock_irq(&this_rq->lock);
spin_lock(&target_rq->lock);
}

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 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/

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