All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: mst@redhat.com
Cc: john.fastabend@gmail.com, jakub.kicinski@netronome.com,
	xiyou.wangcong@gmail.com, jiri@resnulli.us,
	netdev@vger.kernel.org
Subject: Re: [net-next PATCH] net: ptr_ring: otherwise safe empty checks can overrun array bounds
Date: Tue, 02 Jan 2018 13:33:16 -0500 (EST)	[thread overview]
Message-ID: <20180102.133316.589391273753601377.davem@davemloft.net> (raw)
In-Reply-To: <20180102190107-mutt-send-email-mst@kernel.org>

From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 2 Jan 2018 19:01:33 +0200

> On Tue, Jan 02, 2018 at 11:52:19AM -0500, David Miller wrote:
>> From: John Fastabend <john.fastabend@gmail.com>
>> Date: Wed, 27 Dec 2017 19:50:25 -0800
>> 
>> > When running consumer and/or producer operations and empty checks in
>> > parallel its possible to have the empty check run past the end of the
>> > array. The scenario occurs when an empty check is run while
>> > __ptr_ring_discard_one() is in progress. Specifically after the
>> > consumer_head is incremented but before (consumer_head >= ring_size)
>> > check is made and the consumer head is zeroe'd.
>> > 
>> > To resolve this, without having to rework how consumer/producer ops
>> > work on the array, simply add an extra dummy slot to the end of the
>> > array. Even if we did a rework to avoid the extra slot it looks
>> > like the normal case checks would suffer some so best to just
>> > allocate an extra pointer.
>> > 
>> > Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
>> > Fixes: c5ad119fb6c09 ("net: sched: pfifo_fast use skb_array")
>> > Signed-off-by: John Fastabend <john.fastabend@gmail.com>
>> 
>> Applied, thanks John.
> 
> I think that patch is wrong. I'd rather it got reverted.

I agree with John's logic, the asynchronous test is always safe in
this parallel access case and John's change solves the out-of-bounds
test.

If you propose a cleaner way to handle this as a follow-on patch I'll
be happy to consider it.

Thanks.

  parent reply	other threads:[~2018-01-02 18:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28  3:50 [net-next PATCH] net: ptr_ring: otherwise safe empty checks can overrun array bounds John Fastabend
2018-01-02 16:52 ` David Miller
2018-01-02 17:01   ` Michael S. Tsirkin
2018-01-02 17:17     ` Michael S. Tsirkin
2018-01-02 21:27       ` John Fastabend
2018-01-02 23:12         ` Michael S. Tsirkin
2018-01-03  0:25           ` John Fastabend
2018-01-03 15:50             ` Michael S. Tsirkin
2018-01-03 17:46               ` John Fastabend
2018-01-03 18:34                 ` Michael S. Tsirkin
2018-01-02 18:33     ` David Miller [this message]
2018-01-02 16:53 ` Michael S. Tsirkin
2018-01-02 17:01   ` Michael S. Tsirkin

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=20180102.133316.589391273753601377.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiri@resnulli.us \
    --cc=john.fastabend@gmail.com \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=xiyou.wangcong@gmail.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.