After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775015 - gstv4l2bufferpool: lock flush_stop against regular qbuf
gstv4l2bufferpool: lock flush_stop against regular qbuf
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.8.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 772521
Reported: 2016-11-24 15:03 UTC by Philipp Zabel
Modified: 2016-11-24 21:14 UTC
See Also:
GNOME target: ---
GNOME version: ---

gstv4l2bufferpool: lock flush_stop against regular qbuf (3.01 KB, patch)
2016-11-24 15:03 UTC, Philipp Zabel
committed Details | Review

Description Philipp Zabel 2016-11-24 15:03:51 UTC
Created attachment 340688 [details] [review]
gstv4l2bufferpool: lock flush_stop against regular qbuf

Both gst_v4l2_buffer_pool_flush_stop and gst_v4l2_buffer_pool_qbuf manipulate the pool->buffers array and they can be called from different threads.
Lock them properly and let flush_stop move the array contents into a temporary array on the stack to avoid having to call release_buffer under the object lock.
Comment 1 Nicolas Dufresne (ndufresne) 2016-11-24 15:52:24 UTC
Review of attachment 340688 [details] [review]:

This looks safe to remove that race. Looks like the root cause for bug #772521 which I didn't have time to address. It will increase the lock contention, but we can't trade correctness. Queuing / Streaming logic will be removed from the bufferpool in the future. I'll run some tests, and if nothing comes out, I'll backport this.
Comment 2 Nicolas Dufresne (ndufresne) 2016-11-24 16:47:40 UTC
Attachment 340688 [details] pushed as 86f243b - gstv4l2bufferpool: lock flush_stop against regular qbuf
Comment 3 Nicolas Dufresne (ndufresne) 2016-11-24 17:22:03 UTC
[1.8] 1a1871498a94b448c94561160e66de582d84cf67
Comment 4 Nicolas Dufresne (ndufresne) 2016-11-24 21:12:42 UTC
[1.10] 6870dd77f337df6e7b49412190bb76d7643c394d