All of lore.kernel.org
 help / color / mirror / Atom feed
From: Soeren Moch <smoch@web.de>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: dvb_ringbuffer: Add memory barriers
Date: Wed, 11 May 2016 00:03:20 +0200	[thread overview]
Message-ID: <57325AA8.60607@web.de> (raw)
In-Reply-To: <20160507102235.22e096d8@recife.lan>

Hi Mauro,

thanks for looking after this patch.

On 05/07/16 15:22, Mauro Carvalho Chehab wrote:
> Hi Soeren,
>
> Em Sun, 7 Feb 2016 20:22:36 +0100
> Soeren Moch <smoch@web.de> escreveu:
>
>> On 27.12.2015 21:41, Soeren Moch wrote:
>>> Implement memory barriers according to Documentation/circular-buffers.txt:
>>> - use smp_store_release() to update ringbuffer read/write pointers
>>> - use smp_load_acquire() to load write pointer on reader side
>>> - use ACCESS_ONCE() to load read pointer on writer side
>>>
>>> This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
>>> quad core system with different types (PCI, USB) of DVB tuners.
>>>
>>> Signed-off-by: Soeren Moch <smoch@web.de>
>>> Cc: stable@vger.kernel.org # 3.14+
>>
>> Mauro,
>>
>> any news or comments on this?
>> Since this is a real fix for broken behaviour, can you pick this up, please?
>
> The problem here is that I'm very reluctant to touch at the DVB core
> without doing some tests myself, as things like locking can be
> very sensible.

I agree. But this patch adds memory barriers (no locks) according to
Documentation/circular-buffers.txt. It should not be dangerous to
follow these guidelines.
Nevertheless, independent review and testing is always a good idea,
especially in core code.

> I'll try to find some time to take a look on it for Kernel 4.8,

Thanks.

> but I'd like to reproduce the bug locally.
 >
> Could you please provide me enough info to reproduce it (and
> eventually some test MPEG-TS where you know this would happen)?

I used vdr with different types of DVB tuners on a TBS2910 board
(quad core ARM Cortex-A9, see arch/arm/boot/dts/imx6q-tbs2910.dts).
With more than one active cpu core I occasionally see data stream
corruptions in recorded ts streams. This is not the case for one
active cpu.

The problem occurs when dvb_dmxdev_buffer_write() and
dvb_dmxdev_buffer_read() are running simultaneously on different
cpu cores on architectures without strong write ordering (e.g.
on arm, not on x86). Here the write data pointer (written in
dvb_ringbuffer_write() ) can become visible to the other cpu core
(in dvb_ringbuffer_avail() ), before the actual ts packet data is
visible. dvb_ringbuffer_read_user() then can read old ts data,
although new ts data is already written into the ringbuffer
by the other cpu core.

With smp_store_release() and smp_load_acquire() the correct
write ordering is maintained, ts packet data is visible on the
reading cpu core before the updated write pointer.

> I have two DekTek RF generators here, so I should be able to
> play such TS and see what happens with and without the patch
> on x86, arm32 and arm64.

On x86 you should not see any difference, since
smp_store_release() and smp_load_acquire() expand to
simple stores and loads there. On multi-core arm systems
you may see broken ts streams without patch, especially
when reading the dvr device very fast, so that the
dvb_ringbuffer is always close to empty.

Regards,
Soeren


> Regards,
> Mauro
>
>>
>> Regards,
>> Soeren
>>
>>> ---
>>> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>>> Cc: linux-media@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>>
>>> Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
>>> a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
>>> stable kernels?
>>> ---
>>>   drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++++++++++++++-------------
>>>   1 file changed, 14 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c b/drivers/media/dvb-core/dvb_ringbuffer.c
>>> index 1100e98..58b5968 100644
>>> --- a/drivers/media/dvb-core/dvb_ringbuffer.c
>>> +++ b/drivers/media/dvb-core/dvb_ringbuffer.c
>>> @@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void *data, size_t len)
>>>
>>>   int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
>>>   {
>>> -	return (rbuf->pread==rbuf->pwrite);
>>> +	return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
>>>   }
>>>
>>>
>>> @@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
>>>   {
>>>   	ssize_t free;
>>>
>>> -	free = rbuf->pread - rbuf->pwrite;
>>> +	free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
>>>   	if (free <= 0)
>>>   		free += rbuf->size;
>>>   	return free-1;
>>> @@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
>>>   {
>>>   	ssize_t avail;
>>>
>>> -	avail = rbuf->pwrite - rbuf->pread;
>>> +	avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
>>>   	if (avail < 0)
>>>   		avail += rbuf->size;
>>>   	return avail;
>>> @@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
>>>
>>>   void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
>>>   {
>>> -	rbuf->pread = rbuf->pwrite;
>>> +	smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
>>>   	rbuf->error = 0;
>>>   }
>>>   EXPORT_SYMBOL(dvb_ringbuffer_flush);
>>>
>>>   void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
>>>   {
>>> -	rbuf->pread = rbuf->pwrite = 0;
>>> +	smp_store_release(&rbuf->pread, 0);
>>> +	smp_store_release(&rbuf->pwrite, 0);
>>>   	rbuf->error = 0;
>>>   }
>>>
>>> @@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer *rbuf, u8 __user *buf, si
>>>   			return -EFAULT;
>>>   		buf += split;
>>>   		todo -= split;
>>> -		rbuf->pread = 0;
>>> +		smp_store_release(&rbuf->pread, 0);
>>>   	}
>>>   	if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
>>>   		return -EFAULT;
>>>
>>> -	rbuf->pread = (rbuf->pread + todo) % rbuf->size;
>>> +	smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
>>>
>>>   	return len;
>>>   }
>>> @@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8 *buf, size_t len)
>>>   		memcpy(buf, rbuf->data+rbuf->pread, split);
>>>   		buf += split;
>>>   		todo -= split;
>>> -		rbuf->pread = 0;
>>> +		smp_store_release(&rbuf->pread, 0);
>>>   	}
>>>   	memcpy(buf, rbuf->data+rbuf->pread, todo);
>>>
>>> -	rbuf->pread = (rbuf->pread + todo) % rbuf->size;
>>> +	smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
>>>   }
>>>
>>>
>>> @@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf, const u8 *buf, size_t
>>>   		memcpy(rbuf->data+rbuf->pwrite, buf, split);
>>>   		buf += split;
>>>   		todo -= split;
>>> -		rbuf->pwrite = 0;
>>> +		smp_store_release(&rbuf->pwrite, 0);
>>>   	}
>>>   	memcpy(rbuf->data+rbuf->pwrite, buf, todo);
>>> -	rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
>>> +	smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
>>>
>>>   	return len;
>>>   }
>>> @@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer *rbuf,
>>>   			return len - todo;
>>>   		buf += split;
>>>   		todo -= split;
>>> -		rbuf->pwrite = 0;
>>> +		smp_store_release(&rbuf->pwrite, 0);
>>>   	}
>>>   	status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo);
>>>   	if (status)
>>>   		return len - todo;
>>> -	rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
>>> +	smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
>>>
>>>   	return len;
>>>   }
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


  parent reply	other threads:[~2016-05-10 22:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-27 20:41 [PATCH] media: dvb_ringbuffer: Add memory barriers Soeren Moch
2016-02-07 19:22 ` Soeren Moch
2016-05-07 13:22   ` Mauro Carvalho Chehab
2016-05-07 13:26     ` Mauro Carvalho Chehab
2016-05-10 22:03       ` Soeren Moch
2016-05-10 22:03     ` Soeren Moch [this message]
2016-03-16 13:42 ` [PATCH RESEND] " Soeren Moch
  -- strict thread matches above, loose matches on Subject: below --
2016-08-28 16:37 [PATCH] " Soeren Moch

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=57325AA8.60607@web.de \
    --to=smoch@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@osg.samsung.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.