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