linux-kernel - Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Aug 2016 15:59:42 -0400
From:   Waiman Long <waiman.long@....com>
To:     Daniel Vetter <daniel.vetter@...ll.ch>
CC:     Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jason Low <jason.low2@....com>,
        "Ding Tianhong" <dingtianhong@...wei.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        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>,
        Jason Low <jason.low2@...com>,
        Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: [RFC][PATCH -v2 1/4] locking/drm/i915: Kill mutex trickery

On 08/25/2016 03:36 PM, Daniel Vetter wrote:
> On Thu, Aug 25, 2016 at 8:37 PM, Peter Zijlstra<peterz@...radead.org>  wrote:
>> Poking at lock internals is not cool. Since I'm going to change the
>> implementation this will break, take it out.
>>
>> Cc: Chris Wilson<chris@...is-wilson.co.uk>
>> Cc: Daniel Vetter<daniel.vetter@...ll.ch>
>> Signed-off-by: Peter Zijlstra (Intel)<peterz@...radead.org>
> It's horrible, but we die without this in spurious oom. And we haven't
> made much progress in recent years to throw out the locking scheme and
> replace it by something else that doesn't need a recursive mutex.
>
> But initerim I guess we could set our own owner field and check that
> to keep the duct-tape from getting off completely.
> -Daniel

Another alternative is to provide a standard mutex API that returns the 
owner of the lock if there is a real need for this capability. Peeking 
into lock internal is not a good practice.

Cheers,
Longman