mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-10 03:19:40 +00:00
Code Issues 1 Projects Releases Wiki Activity

display: drm: fix race condition setting device type

Browse source 
There is a race condition where g_drm_device_type can be left set to
DRM_DEVICE_RENDERNODES when it shouldn't.

If thread 1 comes in and falls into the last else statement setting up both
RENDERNODES and LEGACY types. And begins to process the first type (RENDERNODES),
it sets g_drm_device_type = RENDERNODES.

Now when thread 2 comes in and sees g_drm_device_type is RENDERNODES, it queues
up that type to be tried but then encounters the lock and has to wait until the
first thread finishes. Once the lock is acquired it will then proceed to ONLY try
RENDERNODES and fail it. But it doesn't try LEGACY. And from then on, all future
attempts will only try RENDERNODES.

So to avoid this situation I have simply moved the acquisition of the lock higher
up in the attached patch.

https://bugzilla.gnome.org/show_bug.cgi?id=747914
This commit is contained in:
Martin Sherburn 2015-04-14 10:54:54 +01:00 committed by Víctor Manuel Jáquez Leal
parent 6f298f6182
commit b5425da1de
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
gst-libs/gst/vaapi/gstvaapidisplay_drm.c
View file

@ -382,6 +382,7 @@ gst_vaapi_display_drm_new (const gchar * device_path)
GstVaapiDisplay *display;
guint types[2], i, num_types = 0;
g_mutex_lock (&g_drm_device_type_lock);
if (device_path)
types[num_types++] = 0;
else if (g_drm_device_type)
@ -391,7 +392,6 @@ gst_vaapi_display_drm_new (const gchar * device_path)
types[num_types++] = DRM_DEVICE_LEGACY;
}
g_mutex_lock (&g_drm_device_type_lock);
for (i = 0; i < num_types; i++) {
g_drm_device_type = types[i];
display = gst_vaapi_display_new (gst_vaapi_display_drm_class (),