lkml.org 
[lkml]   [2000]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Spinlocks, intr levels et al
    Date
    > 
    > Kanoj Sarcar wrote:
    > > Okay. Btw, thinking about this more, spin_lock_irqsave_intercpu()
    > > might be problematic even for a single lock L1. Assume cpu1 has
    > > the lock L1, then cpu2 gets an intr, also tries doing
    > > spin_lock_irqsave_intercpu(&L1). cpu1 now tries to do an inter
    > > cpu function, but cpu2 will not be able to reply. Unless the
    > > inter cpu function uses a suitably higher irq level to interrupt
    > > other cpus.
    > >
    > > Right?
    >

    Okay, I was able to get around my original problem: basically, I think
    it is quite complex to do intercpu interrupts while holding a lock that can
    also be acquired from intr level. So, I recoded a little bit to get
    the ipi's done without holding the lock.

    In case anyone is interested, I can now do kunmap()'s from intr
    context, without deadlocking with ipi's needed for flush_tlb_all().

    > Yes. I think that ipi's with disabled interrupts lead to madness. Just
    > check the tlb flush code: in order to handle crossing invalidates,
    > wait_on_irq() must poll the smp_invalidate_needed bitmap...

    I am willing to tolerate this, since all the complexity is hidden
    inside the flush_tlb* primitives. If the i386 specific version will
    hold intrs high while one flush_tlb* is happening, I am willing to
    let it handle the complexity of multiple, concurrent flush_tlb*s
    by polling bitmaps etc.

    >
    > Btw, I would propose a change of change the prototype for
    > smp_call_function():
    >
    > currently:
    > int smp_call_function(fnc, info, wait, retry)
    >
    > wait: wait until the ipi functions on all other cores have finished
    > retry: schedule() until the required data structures are free
    >
    > returns -EBUSY on error (IIRC)
    >
    > new:
    > void smp_call_function(fnc,info,wait)
    >

    I am assuming you mean go from

    int smp_call_function (void (*func) (void *info), void *info, int nonatomic,
    int wait)

    to

    void smp_call_function (void (*func) (void *info), void *info, int wait)

    > * never fails. panic() [on i386] indirectly relies on
    > smp_call_function(), and panic() shouldn't fail ;)
    > * never schedules, it uses a normal spinlock. [panic() could
    > schedule...]

    Yes, the above two are real problems. OTOH, have you walked the code
    path down under panic() to identify all the scheduling points? Seems
    to me sys_sync is another such point, maybe we should not be doing
    that too?

    Using a spinlock instead of a sleeping lock inside smp_call_function()
    is a good idea.

    > * the call-back is called with disalbed interrupts, and it must not
    > reenable interrupts. [docu clarification]

    Shouldn't this already be happening?

    > * smp_call_function() itself enables interrupts, otherwise we could lock
    > up.[the current code call schedule(), and thus indirectly reenables the
    > interrupts]

    Umm, I don't quite see the point. Are you sure smp_call_function() is never
    called from intr context today? Even if not today, it would be nice to
    let this happen in the future. I see the possibility of deadlock with
    this though (the sleeping lock in smp_call_function() currently prevents
    this I think). To prevent the deadlock, I think smp_call_function() would
    need to have a percpu bitmask of possible ipi's that it needs to check
    while it can not acquire the new spinlock that will replace ther sleeping
    lock.

    Or am I just confused?

    Kanoj

    >
    > The "only" problem is that smp_call_function() is a documented
    > cross-platform function, ie I doubt that Linus would accept the patch,
    > but OTHO the current code it horribly broken.
    >
    > What do you think?
    > --
    > Manfred
    >


    -
    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.028 / U:30.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site