Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4474094ybg; Mon, 21 Oct 2019 09:31:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqyKOW4rX4yKEbb0Ix6+m8VipFCMxA4Wh12L4fkpxxyOe9Ua961ECjPqkCFSyYuAYvAuNAEr X-Received: by 2002:a05:6402:296:: with SMTP id l22mr26153049edv.86.1571675519767; Mon, 21 Oct 2019 09:31:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571675519; cv=none; d=google.com; s=arc-20160816; b=hiWy9YAP0OIiMsdLSbLXOAkldxy7umNIrGu42mclymGv8LA7PGvDiqqQVQAe5hJFuZ 8EbbipRVNvn7ewLGlfocEO2OngDHIcN3/H75M/jl8sRo6CdHAK+tJSJ0yyRCDsHn4Vcg tal6VpVPTquQeGs0uJpD48MiHSQ0eMUVy8NHFjzwzdKJSzm0ZS/dZyI4LmHg6snzbFt8 jGE8LbepBya2L/kpUtoHMKEXF4zWVNJAf6YzHRhzEF/bVDBUn0spEXUWGZAn0D2ojbA4 6ehtaytZlvsuPRb3MfUHyXOIQ5y71jT0mxcQf8UtRSD7sXAHQSC4tD4ee0J7NJ9dcCMr +M8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=6w7dW9mOc7e8F/WURa36AE0ItFqfFxyky2HnpydUOE0=; b=sGq/cSGPMkVcaiNjskmKfP5lCc8x6jYx/NrG2YbYUFfZ1+iLmHSASI0AaUryZNSEyE DIAO/FKlchkCKgCFyLtvbkCYiIKkTHqthJy9nJtwz8mSXmmDCq6MnkRQKCuuzF3ZbHqK m+7m1hId4EJtwP63+iyjrCYZ24fJ4MxKHndFTDMUqFS3D45mX3ZSzMeIomosgVFqNiyy 9c3Wp0scFXBoHo7EPEHMk1hTIFgrPhWtur1iNRySZFpFLys+KUoedUD9exh1JoIVVZfE etD5aXVQ9qwEqPtGHrZ5uv5sZE5SqhobxxopBHKrfJoeJGiTEJKfNT6rINmExWSFFZZ1 j1Qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="eAOjRR/6"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v31si9999234edm.402.2019.10.21.09.31.36; Mon, 21 Oct 2019 09:31:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="eAOjRR/6"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728489AbfJUQb3 (ORCPT + 99 others); Mon, 21 Oct 2019 12:31:29 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:28263 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727101AbfJUQb3 (ORCPT ); Mon, 21 Oct 2019 12:31:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571675488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6w7dW9mOc7e8F/WURa36AE0ItFqfFxyky2HnpydUOE0=; b=eAOjRR/6+t1RmQmV1ycxOR5bpqqgKgCb2CK019RqggMMSW8yS1phRmShQMbf1X5Y87sCps aEshZzdWw0RpmtWFln6oJCQ2Iq4F9s2dR4lXoaTqtHv8wWDDhC7ZaJ/jCLaO5ZzmkWH1OE zW+1Qeugm0u/BbzIKUmVX7zNMTwW0Sk= Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-snuSe-V1OKm9C_fhweXpFg-1; Mon, 21 Oct 2019 12:31:26 -0400 Received: by mail-yb1-f197.google.com with SMTP id 202so10388292ybe.13 for ; Mon, 21 Oct 2019 09:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fsdy/jGiGhYO0LCoELtFkTkwnBVL5KY786AsoYKXAR4=; b=S9qpAclVfQcrmHQ2mTXFeLHWtsm54i6agOgN3XGCx6En0iLd8OwvG9EceIe8yL7pp7 ajYxW+Ym094zTPvtI16AHwcFYxEws4HE0ZGc/W8Ytf6+p2VDP8f3WXvjYRu4Rjpuioch jpD4seCx2oHgUN8uHe+LpS194Gh2J9F0vrFBZHnEa/EhSGK9Ek/pd0bdEi+0U+OwXDIg 9NqVdRGSmUhmHjxJd3o8Qc0ljLwYuQL7yClBMm2hgid9Jw1fsEGJzMluA+c5hHsiJov5 mhEvu8WiaDXjhssHj49e2Hmy8mghkgDBE5BAfZv/IYnfNYuIm8nZy4nnPw8A24ozMIKW pEww== X-Gm-Message-State: APjAAAWa+AxcWlV2/pdYPi1ndA2p+f5qMTyubTwNgpZ6RVsr6ex/NXIV E0Ke6DkwSGkDgowAMd2El2Sf4XWyRoYOPPTj/S/YUqswicekeD9IBBz00cupL9z+0QGem1RXQd9 Xr5CKFdVldGLTvAvdAPI++ALFGoS+pZCKlQ8VTz8X X-Received: by 2002:a05:6902:4c8:: with SMTP id v8mr16247514ybs.66.1571675485764; Mon, 21 Oct 2019 09:31:25 -0700 (PDT) X-Received: by 2002:a05:6902:4c8:: with SMTP id v8mr16247482ybs.66.1571675485370; Mon, 21 Oct 2019 09:31:25 -0700 (PDT) MIME-Version: 1.0 References: <20191021083731.GK15862@gauss3.secunet.de> In-Reply-To: <20191021083731.GK15862@gauss3.secunet.de> From: Tom Rix Date: Mon, 21 Oct 2019 09:31:13 -0700 Message-ID: Subject: Re: [PATCH] xfrm : lock input tasklet skb queue To: Steffen Klassert Cc: herbert@gondor.apana.org.au, davem@davemloft.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org X-MC-Unique: snuSe-V1OKm9C_fhweXpFg-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When preempt rt is full, softirq and interrupts run in kthreads. So it is possible for the tasklet to sleep and for its queue to get modified while it sleeps. On Mon, Oct 21, 2019 at 1:37 AM Steffen Klassert wrote: > > On Sun, Oct 20, 2019 at 08:46:10AM -0700, Tom Rix wrote: > > On PREEMPT_RT_FULL while running netperf, a corruption > > of the skb queue causes an oops. > > > > This appears to be caused by a race condition here > > __skb_queue_tail(&trans->queue, skb); > > tasklet_schedule(&trans->tasklet); > > Where the queue is changed before the tasklet is locked by > > tasklet_schedule. > > > > The fix is to use the skb queue lock. > > > > Signed-off-by: Tom Rix > > --- > > net/xfrm/xfrm_input.c | 11 ++++++++++- > > 1 file changed, 10 insertions(+), 1 deletion(-) > > > > diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c > > index 9b599ed66d97..226dead86828 100644 > > --- a/net/xfrm/xfrm_input.c > > +++ b/net/xfrm/xfrm_input.c > > @@ -758,12 +758,16 @@ static void xfrm_trans_reinject(unsigned long dat= a) > > struct xfrm_trans_tasklet *trans =3D (void *)data; > > struct sk_buff_head queue; > > struct sk_buff *skb; > > + unsigned long flags; > > > > __skb_queue_head_init(&queue); > > + spin_lock_irqsave(&trans->queue.lock, flags); > > skb_queue_splice_init(&trans->queue, &queue); > > > > while ((skb =3D __skb_dequeue(&queue))) > > XFRM_TRANS_SKB_CB(skb)->finish(dev_net(skb->dev), NULL, skb); > > + > > + spin_unlock_irqrestore(&trans->queue.lock, flags); > > } > > > > int xfrm_trans_queue(struct sk_buff *skb, > > @@ -771,15 +775,20 @@ int xfrm_trans_queue(struct sk_buff *skb, > > struct sk_buff *)) > > { > > struct xfrm_trans_tasklet *trans; > > + unsigned long flags; > > > > trans =3D this_cpu_ptr(&xfrm_trans_tasklet); > > + spin_lock_irqsave(&trans->queue.lock, flags); > > As you can see above 'trans' is per cpu, so a spinlock > is not needed here. Also this does not run in hard > interrupt context, so irqsave is also not needed. > I don't see how this can fix anything. > > Can you please explain that race a bit more detailed? >