Hi,
I am getting reports about kfree_skb being called in hard IRQ.
Which context should it be called in?
Regards
Oliver
On Mon, Dec 30, 2002 at 07:32:15PM +0100, Oliver Neukum wrote:
> Hi,
>
> I am getting reports about kfree_skb being called in hard IRQ.
> Which context should it be called in?
kfree_skb() should be called when you are not in hard irq context
(i.e. in_irq() returns false). Same thing for dev_kfree_skb(), which
is a #define for kfree_skb(). Not in hard irq context means you are
either in softirq context (bottom half) or process context.
dev_kfree_skb_irq() should be called when you are in interrupt
context.
dev_kfree_skb_any() should be called when you could be either
executing in interrupt context or not.
--
Muli Ben-Yehuda
"The speed of light really is too slow nowdays." -- Alan Cox
Mulix wrote:
>dev_kfree_skb_any() should be called when you could be either
>executing in interrupt context or not.
>
dev_kfree_skb_any() can misdetect the context: You must not use the
function if you hold an irq spinlock and you might be running from BH or
process context.
cpu 1: cpu 2:
acquire one of the networking bh lock
acquire the driver spin_lock_irq()
hardware interrupt
try to acquire the driver irq spinlock
--> spin.
dev_kfree_skb_any(): !in_irq(), calls kfree_skb
kfree_skb tries to acquire the network lock that
cpu 1 owns
--> spin.
And deadlock.
--
Manfred
Am Montag, 30. Dezember 2002 23:32 schrieb Manfred Spraul:
> Mulix wrote:
> >dev_kfree_skb_any() should be called when you could be either
> >executing in interrupt context or not.
>
> dev_kfree_skb_any() can misdetect the context: You must not use the
> function if you hold an irq spinlock and you might be running from BH or
> process context.
What then shall be used under these circumstances ?
Could you perhaps summarise the issue ?
Regards
Oliver
Oliver Neukum wrote:
>Am Montag, 30. Dezember 2002 23:32 schrieb Manfred Spraul:
>
>
>>Mulix wrote:
>>
>>
>>>dev_kfree_skb_any() should be called when you could be either
>>>executing in interrupt context or not.
>>>
>>>
>>dev_kfree_skb_any() can misdetect the context: You must not use the
>>function if you hold an irq spinlock and you might be running from BH or
>>process context.
>>
>>
>
>What then shall be used under these circumstances ?
>Could you perhaps summarise the issue ?
>
>
When a packet is freed, the upper layers must be notified, for example a
user space process could be waiting for socket buffer space. This can
happen either immediately, or in the next softirq.
dev_kfree_skb_irq() is always ok, although slower than the other
functions. The packet is unconditionally queued and processed later.
dev_kfree_skb_any() tries to optimize it a bit: If it thinks that it's
save to process it now, then the packet is processed immediately. The
autodetection is usually correct, except for the special case I
mentioned. Drivers must work around that.
dev_kfree_skb() always processes the packet immediately. Only permitted
from bottom half context or from process context.
--
Manfred