From: Hans Verkuil <hverkuil@xs4all.nl>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org, m.szyprowski@samsung.com,
pawel@osciak.com, awalls@md.metrocast.net,
Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [RFC PATCH 1/8] vb2: push the mmap semaphore down to __buf_prepare()
Date: Fri, 22 Nov 2013 10:02:49 +0100 [thread overview]
Message-ID: <528F1DB9.6030702@xs4all.nl> (raw)
In-Reply-To: <6539252.6X3kkSkupS@avalon>
On 11/21/2013 08:04 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Thursday 21 November 2013 16:21:59 Hans Verkuil wrote:
>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>
>> Rather than taking the mmap semaphore at a relatively high-level function,
>> push it down to the place where it is really needed.
>>
>> It was placed in vb2_queue_or_prepare_buf() to prevent racing with other
>> vb2 calls, however, I see no way that any race can happen.
>
> What about the following scenario ? Both QBUF calls are performed on the same
> buffer.
>
> CPU 0 CPU 1
> -------------------------------------------------------------------------
> QBUF QBUF
> locks the queue mutex waits for the queue mutex
> vb2_qbuf
> vb2_queue_or_prepare_buf
> __vb2_qbuf
> checks vb->state, calls
> __buf_prepare
> call_qop(q, wait_prepare, q);
> unlocks the queue mutex
> locks the queue mutex
> vb2_qbuf
> vb2_queue_or_prepare_buf
> __vb2_qbuf
> checks vb->state, calls
> __buf_prepare
> call_qop(q, wait_prepare, q);
> unlocks the queue mutex
>
> queue the buffer, set buffer
> state to queue
>
> queue the buffer, set buffer
> state to queue
>
>
> We would thus end up queueing the buffer twice. The vb->state check needs to
> be performed after the brief release of the queue mutex.
Good point, I hadn't thought about that scenario. However, using mmap_sem to
introduce a large critical section just to protect against state changes is IMHO
not the right approach. Why not introduce a VB2_BUF_STATE_PREPARING state?
That's set at the start of __buf_prepare while the queue mutex is still held, and
which prevents other threads of queuing the same buffer again. If the prepare fails,
then the state is reverted back to DEQUEUED.
__fill_v4l2_buffer() will handle the PREPARING state as if it was the DEQUEUED state.
What do you think?
Regards,
Hans
next prev parent reply other threads:[~2013-11-22 9:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-21 15:21 [RFC PATCH 0/8] vb2: various cleanups and improvements Hans Verkuil
2013-11-21 15:21 ` [RFC PATCH 1/8] vb2: push the mmap semaphore down to __buf_prepare() Hans Verkuil
2013-11-21 19:04 ` Laurent Pinchart
2013-11-22 9:02 ` Hans Verkuil [this message]
2013-11-26 15:42 ` Laurent Pinchart
2013-11-27 7:12 ` Hans Verkuil
2013-11-27 8:37 ` Laurent Pinchart
2013-11-21 15:22 ` [RFC PATCH 2/8] vb2: simplify qbuf/prepare_buf by removing callback Hans Verkuil
2013-11-21 15:22 ` [RFC PATCH 3/8] vb2: remove the 'fileio = NULL' hack Hans Verkuil
2013-11-21 15:22 ` [RFC PATCH 4/8] vb2: retry start_streaming in case of insufficient buffers Hans Verkuil
2013-11-21 19:09 ` Laurent Pinchart
2013-11-22 8:43 ` Hans Verkuil
2013-11-26 15:46 ` Laurent Pinchart
2013-11-27 7:17 ` Hans Verkuil
2013-11-27 10:35 ` Laurent Pinchart
2013-11-21 15:22 ` [RFC PATCH 5/8] vb2: don't set index, don't start streaming for write() Hans Verkuil
2013-11-21 15:22 ` [RFC PATCH 6/8] vb2: return ENODATA in start_streaming in case of too few buffers Hans Verkuil
2013-11-21 15:22 ` [RFC PATCH 7/8] vb2: add thread support Hans Verkuil
2013-11-21 15:22 ` [RFC PATCH 8/8] vb2: Add videobuf2-dvb support Hans Verkuil
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=528F1DB9.6030702@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=awalls@md.metrocast.net \
--cc=hans.verkuil@cisco.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=pawel@osciak.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