[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161008164207.GH3568@worktop.programming.kicks-ass.net>
Date: Sat, 8 Oct 2016 18:42:07 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Waiman Long <waiman.long@....com>,
Jason Low <jason.low2@....com>,
Ding Tianhong <dingtianhong@...wei.com>,
Will Deacon <Will.Deacon@....com>,
Ingo Molnar <mingo@...hat.com>,
Imre Deak <imre.deak@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Terry Rudd <terry.rudd@....com>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Chris Wilson <chris@...is-wilson.co.uk>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Rob Clark <robdclark@...il.com>
Subject: Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery
On Sat, Oct 08, 2016 at 04:11:25PM +0200, Thomas Gleixner wrote:
> Well, when you add just trylock_recursive then people are going to use it
> anyway no matter whether it is easy or not.
>
> So if we decide to provide something which supports recursive locking for
> mutexes then we are better off doing it with a proper set of functions and
> not just a single undebugable wrapper.
So ideally I'd say, no recursive stuff at all. But that means the GEM
people need to either do custom hacks (and you know that will spread),
or need to be convinced to rework their locking somehow.
Powered by blists - more mailing lists