lkml.org 
[lkml]   [2000]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Spinlocks, intr levels et al
Date
> 
> Kanoj Sarcar wrote:
> >
> > I have read Documentation/spinlocks.txt.
> >
> > My problem is this: I have a lock L that is acquired from intr level,
> > as well as from process context. Hence, L is grabbed/released with
> > spin_lock_irqsave/spin_unlock_irqrestore. While L is held from process
> > context, it is possible that the code needs to do an intercpu action
> > (eg flush_tlb_all).
>
> I think you cannot do any intercpu action with disabled interrupts: what
> if both cpu's try to perform a different intercpu action?

Yes, your following examples are examples of wrong code, but they do
not involve locks. My current problem is that spin_lock_irqsave,
instead of atomically raising irq and grabbing lock, has been degraded
into two operations, ie, 1. raise irq, 2. grab lock, leading to the
same problem as in your examples.

>
> IIRC I found 3 places that send ipi's with disabled interrupts:
>
> * mtrr: it's easy to fix that, just move the "set_mtrr_prepare()" behind
> the smp_call_function().
>
> * panic(), machine_restart(): both functions call smp_send_stop(), and
> this function uses smp_call_function to issue an ipi.
> I don't know how to fix this problem, therefore I didn't post a patch.
>
>
> > The only solution I can think of is to have a
> > new routine spin_lock_irqsave_intercpu() that raises intr level,
> > tries to get the lock, on failure drops the intr level, and retries.
> >
>
> This is only reliable if there is only _one_ such spinlock. As soon as
> you have 2 users, you have a lock-up.
>

I can not follow your scenario, please give an example, involving
cpu1, cpu2 etc, L1, L2 etc. Here is what the proposed
spin_lock_irqsave_intercpu() function looks like in theory:

extern inline void spin_lock_irqsave_intercpu(lock, flags)
{
loop:
local_irq_save(flags);
if (!spin_trylock(lock)) {
local_irq_restore(flags);
goto loop;
}
}

Kanoj

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

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