linux-kernel - Re: [PATCH -v4 2/8] locking/mutex: Rework mutex::owner

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:   Wed, 12 Oct 2016 12:52:58 -0700
From:   Jason Low <jason.low2@....com>
To:     Davidlohr Bueso <dave@...olabs.net>
Cc:     jason.low2@....com, Peter Zijlstra <peterz@...radead.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Waiman Long <waiman.long@....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>,
        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>
Subject: Re: [PATCH -v4 2/8] locking/mutex: Rework mutex::owner

On Wed, 2016-10-12 at 10:59 -0700, Davidlohr Bueso wrote:
> On Fri, 07 Oct 2016, Peter Zijlstra wrote:
> >+/*
> >+ * Optimistic trylock that only works in the uncontended case. Make sure to
> >+ * follow with a __mutex_trylock() before failing.
> >+ */
> >+static __always_inline bool __mutex_trylock_fast(struct mutex *lock)
> >+{
> >+	unsigned long curr = (unsigned long)current;
> >+
> >+	if (!atomic_long_cmpxchg_acquire(&lock->owner, 0UL, curr))
> >+		return true;
> 
> Do we want to do a ccas check for !lock->owner? Although I can see a possible
> case of 'optimizing for the contended' reasons for nay.

Since this is the fast path version that gets used in mutex_lock(),
ect..., I think it would make sense to keep it like it is so that we
optimize it for the "common" case. This trylock function is more likely
to succeed as it is used for the initial attempt to get the mutex, so I
think we could avoid the ccas in the trylock_fast().

Jason