On 21/04/2016 08:20, Maarten Lankhorst wrote:
Op 20-04-16 om 19:09 schreef John.C.Harrison@xxxxxxxxx:
From: John Harrison <John.C.Harrison@xxxxxxxxx>
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 <chris@xxxxxxxxxxxxxxxxxx>
Date: Wed Apr 13 17:35:15 2016 +0100
drm/i915: Late request cancellations are harmful
I don't believe that patch is the best way to solve the problem.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
