kuznet@xxxxxxxxxxxxx wrote:
>
> Hello!
>
> > - dev_kfree_skb_irq can be called from non-IRQ context
> > in 3c59x.c This looks safe. But should one
> > wrap the call in local_irq_save()/restore() for
> > future-safety?
>
> No, you should not. See below.
>
> > - Should dev_kfree_skb_irq() be doing a local_irq_save()
> > even though it's for IRQ context only?
>
> There exist no such thing as "IRQ context". Each IRQ bucket
> has its own context and they can overlap arbitrarily.
You miss my point.
/* Use this variant when it is known for sure that it
* is executing from interrupt context.
*/
extern __inline__ void dev_kfree_skb_irq(struct sk_buff *skb)
{
if (atomic_dec_and_test(&skb->users)) {
int cpu =smp_processor_id();
unsigned long flags;
local_irq_save(flags);
skb->next = softnet_data[cpu].completion_queue;
softnet_data[cpu].completion_queue = skb;
__cpu_raise_softirq(cpu, NET_TX_SOFTIRQ);
local_irq_restore(flags);
}
}
If "it is known for sure" then why does this function need the
local_irq_save()?
Is it because this CPU could take an interrupt for a different device
and, within the nested ISR, find its completion queue in an inconsistent
state?
--
-akpm-
|