linux-kernel - Re: [RFC][PATCH -v2 4/4] locking/mutex: Add lock handoff to avoid starvation

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 30 Aug 2016 18:32:16 -0400
From:   Waiman Long <waiman.long@....com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     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>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [RFC][PATCH -v2 4/4] locking/mutex: Add lock handoff to avoid
 starvation

On 08/30/2016 07:53 AM, Peter Zijlstra wrote:
> On Mon, Aug 29, 2016 at 05:41:09PM +0200, Peter Zijlstra wrote:
>> On Fri, Aug 26, 2016 at 07:40:34PM -0400, Waiman Long wrote:
>>> On 08/26/2016 11:18 AM, Peter Zijlstra wrote:
>>>> Still need to look at adding spinning to the handoff case.
>>>> Also need to look at writing (much) better changelogs, they stink.
>>>>
>>> I have looked at the handoff code and I didn't see any problem.
>> So I found (or rather the buildbot did) a problem with it.
>>
>> locking-selftest has testcases like:
>>
>>
>> 	lock(&A);
>> 	if (trylock(&A))
>> 		/* fail */
>>
>>    and
>>
>> 	ww_lock(&A)
>> 	if (ww_lock(&A) != -EDEADLK)
>> 		/* fail */
>>
>> But with the 'trylock' accepting the lock if owner==current, in order to
>> accept the hand-off, this breaks in interesting ways.
>>
>> Now, ARCH_MIN_TASKALIGN is at least 8 (mips, s390, parisc) which would
>> give us one more FLAG bit to play with.
>>
>>
>> The below seems to make things happy again..
> Much simpler solution... only accept handoffs when we're stuck in the
> wait loop (which precludes doing recursive locking, since that would've
> failed much earlier).
>
> Now, let me look at that spinner patch you sent.

Yes, that is like my original mutex patch that sets a flag (the handoff 
bit) that disable the optimistic spinner from grabbing the lock. I 
hadn't been thinking about the corner case of a trylock after lock. 
Fortunately, we have test that can uncover those problems.

Cheers,
Longman