Re: [PATCH 3/3] net: skb_queue_purge(): lock/unlock the list only once
From: Eric Dumazet <hidden>
Date: 2017-09-08 16:01:25
Also in:
lkml
On Fri, 2017-09-08 at 05:06 +0000, Michael Witten wrote:
quoted hunk ↗ jump to hunk
Date: Thu, 7 Sep 2017 20:07:40 +0000 With this commit, the list's lock is locked/unlocked only once for the duration of `skb_queue_purge()'. Hitherto, the list's lock has been locked/unlocked every time an item is dequeued; this seems not only inefficient, but also incorrect, as the whole point of `skb_queue_purge()' is to clear the list, presumably without giving anything else a chance to manipulate the list in the interim. Signed-off-by: Michael Witten <redacted> --- net/core/skbuff.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)diff --git a/net/core/skbuff.c b/net/core/skbuff.c index 68065d7d383f..66c0731a2a5f 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c@@ -2834,9 +2834,13 @@ EXPORT_SYMBOL(skb_dequeue_tail); */ void skb_queue_purge(struct sk_buff_head *list) { + unsigned long flags; struct sk_buff *skb; - while ((skb = skb_dequeue(list)) != NULL) + + spin_lock_irqsave(&list->lock, flags); + while ((skb = __skb_dequeue(list)) != NULL) kfree_skb(skb); + spin_unlock_irqrestore(&list->lock, flags); } EXPORT_SYMBOL(skb_queue_purge);
No, this is very wrong : Holding hard IRQ for a potential very long time is going to break horribly. Some lists can have 10,000+ skbs in them. Note that net-next tree is currently closed, please read Documentation/networking/netdev-FAQ.txt