On Thu, Nov 26, 2015 at 12:19:43PM +0100, Thomas Hellstrom wrote:
> On 11/25/2015 03:56 PM, Chris Wilson wrote:
> > On Wed, Nov 25, 2015 at 03:44:04PM +0100, Thomas Hellstrom wrote:
> >> Do you need to take the mutex around other event pullers as well?
> > We would. I checked in drm/*.c for other u
On 11/25/2015 03:56 PM, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 03:44:04PM +0100, Thomas Hellstrom wrote:
>> Do you need to take the mutex around other event pullers as well?
> We would. I checked in drm/*.c for other users, but not the drivers.
> A quick git grep doesn't show any likely cand
Do you need to take the mutex around other event pullers as well?
So that no such process thinks it has pulled all events and then
suddenly an event reappears?
I think there was some event pulling code in one of the drivers, but I
might be wrong.
The close() code should be safe against this.
/Tho
On Wed, Nov 25, 2015 at 03:44:04PM +0100, Thomas Hellstrom wrote:
> Do you need to take the mutex around other event pullers as well?
We would. I checked in drm/*.c for other users, but not the drivers.
A quick git grep doesn't show any likely candidates, they appear to be
private event lists.
>
The previous patch reintroduced a race condition whereby a failure in
one reader may allow a second reader to see out-of-order events.
Introduce a mutex to serialise readers so that an event is completed in
its entirety before another reader may process an event. The two readers
may race against ea
