similar to: [PATCH] ptr_ring: add barriers

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 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

While running a multiple VM testscase with each VM running iperf traffic between others the following kernel NULL pointer exception was seen. Race appears when the tun driver instance of one VM calls skb_array_produce (from tun_net_xmit) and the the destined VM's skb_array_consume (from tun_ring_recv), which could run concurrently on another core. Due to which the sock_wfree gets called again

While running a multiple VM testscase with each VM running iperf traffic between others the following kernel NULL pointer exception was seen. Race appears when the tun driver instance of one VM calls skb_array_produce (from tun_net_xmit) and the the destined VM's skb_array_consume (from tun_ring_recv), which could run concurrently on another core. Due to which the sock_wfree gets called again

On Wed, Dec 06, 2017 at 02:51:41PM +0530, George Cherian wrote: > Hi Michael, > > > On 12/06/2017 12:59 AM, 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. > This is not the exact

Hi Michael, On 12/06/2017 12:59 AM, 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. This is not the exact situation we are seeing. Let me try to explain the situation Affected on ARM64 platform. 1) tun_net_xmit calls

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

Hi Michael, _____________________________ From: Michael S. Tsirkin <mst at redhat.com> Sent: Wednesday, December 6, 2017 7:05 PM Subject: Re: [PATCH] ptr_ring: Add barriers to fix NULL-pointer exception To: Cherian, George <george.cherian at cavium.com> Cc: <linux-kernel at vger.kernel.org>, <davem at davemloft.net>, <jasowang at redhat.com>, <edumazet at

Hi Michael, _____________________________ From: Michael S. Tsirkin <mst at redhat.com> Sent: Wednesday, December 6, 2017 7:05 PM Subject: Re: [PATCH] ptr_ring: Add barriers to fix NULL-pointer exception To: Cherian, George <george.cherian at cavium.com> Cc: <linux-kernel at vger.kernel.org>, <davem at davemloft.net>, <jasowang at redhat.com>, <edumazet at

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

Hi all: This series tries to switch to use skb array in tun. This is used to eliminate the spinlock contention between producer and consumer. The conversion was straightforward: just introdce a tx skb array and use it instead of sk_receive_queue. A minor issue is to keep the tx_queue_len behaviour, since tun used to use it for the length of sk_receive_queue. This is done through: - add the

On Wed, Dec 06, 2017 at 09:57:41AM +0000, George Cherian wrote: > While running a multiple VM testscase with each VM running iperf > traffic between others the following kernel NULL pointer exception > was seen. > > Race appears when the tun driver instance of one VM calls skb_array_produce > (from tun_net_xmit) and the the destined VM's skb_array_consume > (from

On Tue, Mar 21, 2017 at 12:04:40PM +0800, Jason Wang wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/ptr_ring.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h > index 6c70444..4771ded 100644 > ---

On Tue, Mar 21, 2017 at 12:04:40PM +0800, Jason Wang wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/ptr_ring.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h > index 6c70444..4771ded 100644 > ---

Hi all, Although [smp_]read_barrier_depends() became part of READ_ONCE() in commit 76ebbe78f739 ("locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()"), it still limps on in the Linux memory model with the sinister hope of attracting innocent new users so that it becomes impossible to remove altogether. Let's strike before it's too late: there's only

Hello! On 3/21/2017 7:04 AM, Jason Wang wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/ptr_ring.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h > index 6c70444..4771ded 100644 > --- a/include/linux/ptr_ring.h > +++

Hello! On 3/21/2017 7:04 AM, Jason Wang wrote: > Signed-off-by: Jason Wang <jasowang at redhat.com> > --- > include/linux/ptr_ring.h | 65 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 65 insertions(+) > > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h > index 6c70444..4771ded 100644 > --- a/include/linux/ptr_ring.h > +++

On Fri, Jun 17, 2016 at 03:41:20AM +0300, Michael S. Tsirkin wrote: > Would it help to have ptr_ring_resize that gets an array of > rings and resizes them both to same length? OK, here it is. Untested so far, and no skb wrapper. Pls let me know whether this is what you had in mind. --> ptr_ring: support resizing multiple queues Signed-off-by: Michael S. Tsirkin <mst at