Re: Problem with dev_kfree_skb_any() in 2.6.0

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Tue, 2003-12-30 at 15:51, David S. Miller wrote:

> There is one important detail not mentioned.
> 
> If we let the TX free occur in cpu IRQ disabled context, the
> BH to actually do the work will occur as some indeterminate
> time in the future after the top level IRQ spinlock release
> occurs.
> 
> Unlike local_bh_enable(), local_irq_enable() does not run
> softirq work.  Similarly when comparing IRQ handler return
> (which also runs softirq work if pending).

Ok, checked that with Rusty and it seems that scheduling the
softirq will wakeup softirqd when done from non-interrupt level,
so it should just work to call dev_kfree_skb_irq() from this
task context.

inline void raise_softirq_irqoff(unsigned int nr)
{
        __raise_softirq_irqoff(nr);
 
        /*
         * If we're in an interrupt or softirq, we're done
         * (this also catches softirq-disabled code). We will
         * actually run the softirq once we return from
         * the irq or softirq.
         *
         * Otherwise we wake up ksoftirqd to make sure we
         * schedule the softirq soon.
         */
        if (!in_interrupt())
                wakeup_softirqd();
}
 
So that should be ok to just call the _irq version in these
cases. Those aren't performance critical code path anyway,
it's power management when the machine is going to sleep in
this specific case in sungem, and close() codepath in
general.

Ben.