[Mesa-stable] [PATCH 1/4] i965/sync: Fix uninitalized usage and leak of mutex

[Emil Velikov]

On 10 October 2016 at 11:52, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 7 October 2016 at 19:23, Chad Versace <chad at kiwitree.net> wrote:
>> On Thu 06 Oct 2016, Emil Velikov wrote:
>>> Hi Chad,
>>>
>>> On 4 October 2016 at 23:37, Chad Versace <chadversary at chromium.org> wrote:
>>> > We locked an unitialized mutex in the callstack
>>> >     glClientWaitSync
>>> >     intel_gl_client_wait_sync
>>> >     brw_fence_client_wait_sync
>>> > because we forgot to initialize it in intel_gl_fence_sync.
>>> > (The EGLSync codepath didn't have this bug. It initialized the mutex in
>>> > intel_dri_create_sync).
>>> >
>>> > We also forgot to tear down (mtx_destroy) the mutex when destroying
>>> > the sync object.
>>> >
>>> > Cc: mesa-stable at lists.freedesktop.org
>>
>>> Do you have a few minutes to roll an similar fix for i915 ? It should
>>> be identical (barring naming fixes) to this.
>>
>> I would do it if i915's sync object already included a mutex. But it
>> doesn't.
>>
>>     struct intel_sync_object {
>>        struct gl_sync_object Base;
>>
>>        /** Batch associated with this sync object */
>>        drm_intel_bo *bo;
>>     };
>>
>> I hesitate to make non-obvious changes (like adding a mutex) to a driver
>> that I'm unable to test.
> Hmm yes. Seems like Mauro's i915 port of
> 4f48674d51f03d8c954a89dfc49539a1dc750c4d never made it.
>
Correction - the series including test numbers is out waiting for
Ack/Rb/other from interested devs [1].
Considering the nice numbers, shortage of input and straightforward
port, in pull the lot in the next few days.

If anyone wants to chip-in for/against the lot, please do so.

Thanks
Emil

[1] https://patchwork.freedesktop.org/series/9854/