public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* question on context of kfree_skb()
@ 2002-12-30 18:32 Oliver Neukum
  2002-12-30 22:26 ` Muli Ben-Yehuda
  0 siblings, 1 reply; 5+ messages in thread
From: Oliver Neukum @ 2002-12-30 18:32 UTC (permalink / raw)
  To: linux-kernel

Hi,

I am getting reports about kfree_skb being called in hard IRQ.
Which context should it be called in?

	Regards
		Oliver


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question on context of kfree_skb()
  2002-12-30 18:32 question on context of kfree_skb() Oliver Neukum
@ 2002-12-30 22:26 ` Muli Ben-Yehuda
  0 siblings, 0 replies; 5+ messages in thread
From: Muli Ben-Yehuda @ 2002-12-30 22:26 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: linux-kernel

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 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question on context of kfree_skb()
@ 2002-12-30 22:32 Manfred Spraul
  2002-12-31  0:57 ` Oliver Neukum
  0 siblings, 1 reply; 5+ messages in thread
From: Manfred Spraul @ 2002-12-30 22:32 UTC (permalink / raw)
  To: Muli Ben-Yehuda; +Cc: Oliver Neukum, linux-kernel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question on context of kfree_skb()
  2002-12-30 22:32 Manfred Spraul
@ 2002-12-31  0:57 ` Oliver Neukum
  2002-12-31  9:31   ` Manfred Spraul
  0 siblings, 1 reply; 5+ messages in thread
From: Oliver Neukum @ 2002-12-31  0:57 UTC (permalink / raw)
  To: Manfred Spraul, Muli Ben-Yehuda; +Cc: linux-kernel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: question on context of kfree_skb()
  2002-12-31  0:57 ` Oliver Neukum
@ 2002-12-31  9:31   ` Manfred Spraul
  0 siblings, 0 replies; 5+ messages in thread
From: Manfred Spraul @ 2002-12-31  9:31 UTC (permalink / raw)
  To: Oliver Neukum; +Cc: Muli Ben-Yehuda, linux-kernel

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-12-31  9:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-12-30 18:32 question on context of kfree_skb() Oliver Neukum
2002-12-30 22:26 ` Muli Ben-Yehuda
  -- strict thread matches above, loose matches on Subject: below --
2002-12-30 22:32 Manfred Spraul
2002-12-31  0:57 ` Oliver Neukum
2002-12-31  9:31   ` Manfred Spraul

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox