linux-kernel.vger.kernel.org archive mirror
 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: 7+ 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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).