[lkml]   [2002]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [announce, patch, RFC] "big IRQ lock" removal, IRQ cleanups.

    > > [...] To do this from irq.c means that it must exit with interrupts off
    > > and the the low level code needs to keep them off till the irtn. [...]

    > yes, we are very careful to keep irqs disabled in do_IRQ(), both before
    > and after calling the handler.

    Note that smp_xxx_interrupt() functions must be carefull
    with preemt_{disable,enable} brackets.

    For example, smp_invalidate_interrupt() may be preempted
    after put_cpu(). Probably not big deal (it is return path),
    but it is better to use preempt_enable_no_resched() here -
    let ret_from_intr: do its job.

    smp_{error,spurious,thermal}_interrupt() - all of them
    use printk() without bumping preemt_count and have problem
    after spin_unlock_irqrestore(&logbuf_lock, flags).

    If these problems worth fixing, then preempt_stop (cli)
    can be killed in entry.S:ret_from_intr(), yes? If i understand
    correctly none of the irq handlers should return to low level
    code with irq enabled.


    May I suggest somebody with good english fix
    It states, that disabled interrupts prevents preemption.
    Yes, but only in a sense, that the delivery of reschedule
    interrupt is suppressed.

    Process with irqs disabled and current->preempt_count == 0 can
    be preempted (with interrupts enabled) after spin_lock/unlock etc.
    Even in UP case preemption can happen while calling wake_up_...().

    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:27    [W:0.022 / U:7.256 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site