| Message ID | 20180104112507.GB6437@gondor.apana.org.au |
|---|---|
| State | New, archived |
| Headers | show |
| Series |
|
| Related | show |
On Thu, Jan 04, 2018 at 10:25:07PM +1100, Herbert Xu wrote: > On Thu, Jan 04, 2018 at 12:20:26PM +0100, Artem Savkov wrote: > > > Right, thats a better solution. > > > > Reported-and-tested-by: Artem Savkov <asavkov@redhat.com> > > Thanks! > > But I just realised that this patch is based on my dirty tree. > So here is a rebased version: > > ---8<--- > 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@redhat.com> > Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets...") > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Applied, thanks everyone!
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c index 444fa37..9dbf425 100644 --- a/net/xfrm/xfrm_input.c +++ b/net/xfrm/xfrm_input.c @@ -508,7 +508,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; }