All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet.com>
To: Tom Rix <trix@redhat.com>
Cc: <herbert@gondor.apana.org.au>, <davem@davemloft.net>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Joerg Vehlow <lkml@jv-coder.de>
Subject: Re: [PATCH v2 1/1] xfrm : lock input tasklet skb queue
Date: Thu, 24 Oct 2019 12:31:34 +0200	[thread overview]
Message-ID: <20191024103134.GD13225@gauss3.secunet.de> (raw)
In-Reply-To: <CACVy4SUkfn4642Vne=c1yuWhne=2cutPZQ5XeXz_QBz1g67CrA@mail.gmail.com>

On Tue, Oct 22, 2019 at 05:22:04PM -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.
> 
> This is the original work of Joerg Vehlow <joerg.vehlow@aox-tech.de>
> https://lkml.org/lkml/2019/9/9/111
>   xfrm_input: Protect queue with lock
> 
>   During the skb_queue_splice_init the tasklet could have been preempted
>   and __skb_queue_tail called, which led to an inconsistent queue.
> 
> ifdefs for CONFIG_PREEMPT_RT_FULL added to reduce runtime effects
> on the normal kernel.

Has Herbert commented on your initial patch, please
fix PREEMPT_RT_FULL instead. There are certainly many
more codepaths that take such assumptions. You can not
fix this by distributing a spin_lock_irqsave here
and there.


  reply	other threads:[~2019-10-24 10:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  0:22 [PATCH v2 1/1] xfrm : lock input tasklet skb queue Tom Rix
2019-10-24 10:31 ` Steffen Klassert [this message]
2019-10-25  9:37   ` Joerg Vehlow
2019-10-25  9:47     ` Sebastian Andrzej Siewior
2019-10-25 10:14       ` Joerg Vehlow
2019-10-25 10:22         ` Sebastian Andrzej Siewior
2019-10-25 14:26           ` Tom Rix
2019-10-25 19:25             ` Sebastian Andrzej Siewior
2019-10-28 10:44           ` Joerg Vehlow
2019-10-28 15:15             ` Sebastian Andrzej Siewior
2019-10-29  7:33               ` Joerg Vehlow
2019-11-18 10:46                 ` Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191024103134.GD13225@gauss3.secunet.de \
    --to=steffen.klassert@secunet.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@jv-coder.de \
    --cc=netdev@vger.kernel.org \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.