[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1519831222.194131703@decadent.org.uk>
Date: Wed, 28 Feb 2018 15:20:22 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org,
"Steffen Klassert" <steffen.klassert@...unet.com>,
"Herbert Xu" <herbert@...dor.apana.org.au>
Subject: [PATCH 3.2 084/140] xfrm: Use __skb_queue_tail in xfrm_trans_queue
3.2.100-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <herbert@...dor.apana.org.au>
commit d16b46e4fd8bc6063624605f25b8c0835bb1fbe3 upstream.
We do not need locking in xfrm_trans_queue because it is designed
to use per-CPU buffers. However, the original code incorrectly
used skb_queue_tail which takes the lock. This patch switches
it to __skb_queue_tail instead.
Reported-and-tested-by: Artem Savkov <asavkov@...hat.com>
Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets...")
Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
net/xfrm/xfrm_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -324,7 +324,7 @@ int xfrm_trans_queue(struct sk_buff *skb
return -ENOBUFS;
XFRM_TRANS_SKB_CB(skb)->finish = finish;
- skb_queue_tail(&trans->queue, skb);
+ __skb_queue_tail(&trans->queue, skb);
tasklet_schedule(&trans->tasklet);
return 0;
}
Powered by blists - more mailing lists