All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jason Wang <jasowang@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	George Cherian <george.cherian@cavium.com>,
	davem@davemloft.net, edumazet@google.com, netdev@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH] ptr_ring: add barriers
Date: Wed, 6 Dec 2017 04:53:56 +0200	[thread overview]
Message-ID: <20171206045247-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <96e8cec4-37db-b41d-b02b-767a21d9efba@redhat.com>

On Wed, Dec 06, 2017 at 10:31:39AM +0800, Jason Wang wrote:
> 
> 
> On 2017年12月06日 03:29, Michael S. Tsirkin wrote:
> > Users of ptr_ring expect that it's safe to give the
> > data structure a pointer and have it be available
> > to consumers, but that actually requires an smb_wmb
> > or a stronger barrier.
> > 
> > In absence of such barriers and on architectures that reorder writes,
> > consumer might read an un=initialized value from an skb pointer stored
> > in the skb array.  This was observed causing crashes.
> > 
> > To fix, add memory barriers.  The barrier we use is a wmb, the
> > assumption being that producers do not need to read the value so we do
> > not need to order these reads.
> > 
> > Reported-by: George Cherian <george.cherian@cavium.com>
> > Suggested-by: Jason Wang <jasowang@redhat.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > 
> > George, could you pls report whether this patch fixes
> > the issue for you?
> > 
> > This seems to be needed in stable as well.
> > 
> > 
> > 
> > 
> >   include/linux/ptr_ring.h | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
> > index 37b4bb2..6866df4 100644
> > --- a/include/linux/ptr_ring.h
> > +++ b/include/linux/ptr_ring.h
> > @@ -101,12 +101,18 @@ static inline bool ptr_ring_full_bh(struct ptr_ring *r)
> >   /* Note: callers invoking this in a loop must use a compiler barrier,
> >    * for example cpu_relax(). Callers must hold producer_lock.
> > + * Callers are responsible for making sure pointer that is being queued
> > + * points to a valid data.
> >    */
> >   static inline int __ptr_ring_produce(struct ptr_ring *r, void *ptr)
> >   {
> >   	if (unlikely(!r->size) || r->queue[r->producer])
> >   		return -ENOSPC;
> > +	/* Make sure the pointer we are storing points to a valid data. */
> > +	/* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
> > +	smp_wmb();
> > +
> >   	r->queue[r->producer++] = ptr;
> >   	if (unlikely(r->producer >= r->size))
> >   		r->producer = 0;
> > @@ -275,6 +281,9 @@ static inline void *__ptr_ring_consume(struct ptr_ring *r)
> >   	if (ptr)
> >   		__ptr_ring_discard_one(r);
> > +	/* Make sure anyone accessing data through the pointer is up to date. */
> > +	/* Pairs with smp_wmb in __ptr_ring_produce. */
> > +	smp_read_barrier_depends();
> >   	return ptr;
> >   }
> 
> I was thinking whether or not it's better to move those to the callers. Then
> we can save lots of barriers in e.g batch consuming.
> 
> Thanks

Batch consumers only do smp_read_barrier_depends which is free on
non-alpha. I suggest we do the simple thing for stable and reserve
optimizations for later.

-- 
MST

  reply	other threads:[~2017-12-06  2:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 19:29 [PATCH] ptr_ring: add barriers Michael S. Tsirkin
2017-12-05 19:29 ` Michael S. Tsirkin
2017-12-06  2:31 ` Jason Wang
2017-12-06  2:31 ` Jason Wang
2017-12-06  2:53   ` Michael S. Tsirkin [this message]
2017-12-06  3:21     ` Jason Wang
2017-12-06  3:21     ` Jason Wang
2017-12-06  2:53   ` Michael S. Tsirkin
2017-12-06  9:21 ` George Cherian
2017-12-06 12:46   ` Michael S. Tsirkin
2017-12-06 12:46     ` Michael S. Tsirkin
2017-12-06  9:21 ` George Cherian
2017-12-08 18:08 ` David Miller
2017-12-08 18:08 ` David Miller
2017-12-11 15:53 ` David Miller
2017-12-12  6:28   ` George Cherian
2017-12-12  6:28   ` George Cherian
2017-12-11 15:53 ` David Miller

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=20171206045247-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=george.cherian@cavium.com \
    --cc=jasowang@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.org \
    /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.