On Sun, Jul 17, 2016 at 10:54:51PM +0100, Chris Wilson wrote:
> On Sun, Jul 17, 2016 at 11:45:44AM -0700, Davidlohr Bueso wrote:
> > In addition, we can simplify the overall function wrt (2), by first
> > checking if we are the lock owner, then address the trylock and
> > deal with (2) if locked/co
Currently i915_gem_shrinker_lock() suffers from a few issues:
(1) In the attempt to avoid recursive locking, the mutex owner is
consulted. This is obviously nasty and extends the standard api
with artifacts like mutex_is_locked_by() deep in driver code.
(2) If the lock is taken by another task, t
On Sun, Jul 17, 2016 at 11:45:44AM -0700, Davidlohr Bueso wrote:
> In addition, we can simplify the overall function wrt (2), by first
> checking if we are the lock owner, then address the trylock and
> deal with (2) if locked/contended by a traditional mutex_lock().
> This should be safe consideri
