Op 20-04-16 om 19:09 schreef john.c.harri...@intel.com:
> From: John Harrison <john.c.harri...@intel.com>
>
> If an execbuff IOCTL call fails for some reason, it would leave the
> request in the client list. The request clean up code would remove
> this but only later on and only after the reference count has dropped
> to zero. The entire sequence is contained within the driver mutex
> lock. However, there is still a hole such that any code which does not
> require the mutex lock could still find the request on the client list
> and start using it. That would lead to broken reference counts, use of
> dangling pointers and all sorts of other nastiness.
>
> The throttle IOCTL in particular does not acquire the mutex and does
> process the client list. And the likely situation of the execbuff
> IOCTL failing is when the system is busy with lots of work
> outstanding. That is exactly the situation where the throttle IOCTL
> would try to wait on a request.
>
> Currently, this hole is tiny - the gap between the reference count
> dropping to zero and the free function being called in response.
> However the next patch in this series enlarges that gap considerably
> by deferring the free function (to remove the need for the mutex lock
> when unreferencing requests).
>
Seems to already have been fixed by
commit aa9b78104fe3210758fa9e6c644e9a108d371e8b
Author: Chris Wilson <ch...@chris-wilson.co.uk>
Date: Wed Apr 13 17:35:15 2016 +0100
drm/i915: Late request cancellations are harmful
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
