Skip to contentSkip to conversation

question on context of kfree_skb()

DISCUSSION Manfred Spraul 2 participants 3 messages Dec 30, 2002 – Dec 31, 2002

lore
Share & tools
lore
#0 lore raw
Quoted 3 lines · Mulix

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

#1 lore raw

Am Montag, 30. Dezember 2002 23:32 schrieb Manfred Spraul:

Quoted 7 lines
Quoted 2 lines · Mulix

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

#2 lore raw
Quoted 10 lines · Oliver Neukum

Am Montag, 30. Dezember 2002 23:32 schrieb Manfred Spraul:

Quoted 7 lines
Quoted 4 lines · Mulix

dev_kfree_skb_any() should be called when you could be either executing in interrupt context or not.

Quoted 10 lines
Quoted 5 lines

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