Messages in this thread | | | Subject | Re: Problem with dev_kfree_skb_any() in 2.6.0 | From | Benjamin Herrenschmidt <> | Date | Tue, 30 Dec 2003 17:14:18 +1100 |
| |
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.
- 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/
| |