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 747914 - Race condition in gstvaapidisplay_drm.c device type
Race condition in gstvaapidisplay_drm.c device type
Status: RESOLVED FIXED
Product: gstreamer-vaapi
Classification: Other
Component: general
0.5.10
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks: 743569
 
 
Reported: 2015-04-15 13:20 UTC by Martin Sherburn
Modified: 2015-04-16 11:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to fix race condition (1.19 KB, patch)
2015-04-15 13:20 UTC, Martin Sherburn
committed Details | Review

Description Martin Sherburn 2015-04-15 13:20:06 UTC
Created attachment 301627 [details] [review]
Patch to fix race condition

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.

Regards,

Martin Sherburn
Comment 1 Víctor Manuel Jáquez Leal 2015-04-16 11:07:10 UTC
Comment on attachment 301627 [details] [review]
Patch to fix race condition

commit b5425da1de221b678c8819df543f2775f1cf1ad7
Author: Martin Sherburn <martin.sherburn@datapath.co.uk>
Date:   Tue Apr 14 10:54:54 2015 +0100

    display: drm: fix race condition setting device type
    
    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