* [PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"
@ 2018-11-22 11:43 Hans Verkuil
2018-11-23 19:52 ` Sasha Levin
0 siblings, 1 reply; 2+ messages in thread
From: Hans Verkuil @ 2018-11-22 11:43 UTC (permalink / raw)
To: stable
Cc: Linux Media Mailing List, Sakari Ailus, Greg Kroah-Hartman, Sasha Levin
This reverts commit 9ac47200b51cb09d2f15dbefa67e0412741d98aa.
This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move
buffer cache synchronisation to prepare from queue") which isn't
present in 4.9.
So as a result you get an UNBALANCED message in the kernel log if
this patch is applied:
vb2: counters for queue ffffffc0f3687478, buffer 3: UNBALANCED!
vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
vb2: buf_queue: 806 buf_done: 806
vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
vb2: get_userptr: 0 put_userptr: 0
vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805
Reverting this patch solves this regression.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
Probably two reasons why this slipped through:
1) The patch was missing a Fixes: tag
2) I was probably CC-ed about this when it was about to be added to 4.9
but didn't realize that that was wrong.
---
drivers/media/v4l2-core/videobuf2-core.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c
index f7ca1fa..4df4a1f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -914,12 +914,9 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);
- if (state != VB2_BUF_STATE_QUEUED &&
- state != VB2_BUF_STATE_REQUEUEING) {
- /* sync buffers */
- for (plane = 0; plane < vb->num_planes; ++plane)
- call_void_memop(vb, finish, vb->planes[plane].mem_priv);
- }
+ /* sync buffers */
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, finish, vb->planes[plane].mem_priv);
spin_lock_irqsave(&q->done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
--
2.10.2
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing"
2018-11-22 11:43 [PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing" Hans Verkuil
@ 2018-11-23 19:52 ` Sasha Levin
0 siblings, 0 replies; 2+ messages in thread
From: Sasha Levin @ 2018-11-23 19:52 UTC (permalink / raw)
To: Hans Verkuil
Cc: stable, Linux Media Mailing List, Sakari Ailus, Greg Kroah-Hartman
On Thu, Nov 22, 2018 at 12:43:56PM +0100, Hans Verkuil wrote:
>This reverts commit 9ac47200b51cb09d2f15dbefa67e0412741d98aa.
>
>This commit fixes a bug in upstream commit a136f59c0a1f ("vb2: Move
>buffer cache synchronisation to prepare from queue") which isn't
>present in 4.9.
>
>So as a result you get an UNBALANCED message in the kernel log if
>this patch is applied:
>
>vb2: counters for queue ffffffc0f3687478, buffer 3: UNBALANCED!
>vb2: buf_init: 1 buf_cleanup: 1 buf_prepare: 805 buf_finish: 805
>vb2: buf_queue: 806 buf_done: 806
>vb2: alloc: 0 put: 0 prepare: 806 finish: 805 mmap: 0
>vb2: get_userptr: 0 put_userptr: 0
>vb2: attach_dmabuf: 1 detach_dmabuf: 1 map_dmabuf: 805 unmap_dmabuf: 805
>vb2: get_dmabuf: 0 num_users: 1609 vaddr: 0 cookie: 805
>
>Reverting this patch solves this regression.
>
>Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
I've queued both reverts to their respective branches, thank you.
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2018-11-24 6:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-22 11:43 [PATCH for v4.9] Revert "media: videobuf2-core: don't call memop 'finish' when queueing" Hans Verkuil
2018-11-23 19:52 ` Sasha Levin
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).