Re: 2.4.7 softirq incorrectness.

From: Andrea Arcangeli (andrea@suse.de)
Date: Sun Jul 22 2001 - 18:34:16 EST


On Mon, Jul 23, 2001 at 06:44:10AM +1000, Rusty Russell wrote:
> This current code is bogus. Consider:
> spin_lock_irqsave(flags);
> cpu_raise_softirq(this_cpu, NET_RX_SOFTIRQ);
> spin_unlock_irqrestore(flags);

What kernel are you looking at? There's no such code in 2.4.7, the only
two raise of the NET_RX_SOFTIRQ softirq are in dev.c in net_rx_action
and netif_rx:

here the one in netif_rx:

                        __cpu_raise_softirq(this_cpu, NET_RX_SOFTIRQ);
                        local_irq_restore(flags);

here the one in net_rx_action:

        /* This already runs in BH context, no need to wake up BH's */
        __cpu_raise_softirq(this_cpu, NET_RX_SOFTIRQ);
        local_irq_enable();

> Oops... softirq not run until the next interrupt. So, EITHER:

The first netif_rx is required to run from interrupt handler (otherwise
we should have executed cpu_raise_softirq and not __cpu_raise_softirq)
so we cannot miss the do_softirq in the return path from do_IRQ() and so
we cannot wait for the next incoming interrupt (if we have a overflow of
the do_softirq loop ksoftirqd will take care of it without waiting for
the next interrupt as it could instead happen in old 2.4 kernels).

The second net_rx_action is running into the softirq code itself that
will marks itself runnable again and this will generate a do_softirq
overflow that is handled gracefully by ksoftirqd again without waiting
for the next interrupt (in old 2.4 kernels you had to wait for the next
irq instead).

I cannot see any problem.

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



This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 21:00:16 EST