linux-kernel - Re: xchg in fastpath for mutex unlock [mutex-xchg.h]

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] [day] [month] [year] [list]

Message-ID: <20121001214557.GA19126@liondog.tnic>
Date:	Mon, 1 Oct 2012 23:45:57 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Shantanu Gupta <shans95g@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: xchg in fastpath for mutex unlock [mutex-xchg.h]

On Fri, Sep 28, 2012 at 04:18:41PM +0530, Shantanu Gupta wrote:
> Hello,
> 
> I am currently studying mutex(es) and was referring to linux sources
> for it's implementation. However I noticed one shortcoming, in
> "/include/asm-generic/mutex-xchg.h" of the master branch inside
> __mutex_fastpath_trylock, Why doesn't the kernel use a cmpxchg instead
> of dirtying the value with xchg ?
> 
> (The only thing that came to my mind was that x86_x64 implementation
> mentioned that all x86_x64 cpu(s) have cmpxchg leading me to
> assumption that certain archs can have xchg but not cmpxchg, so is it
> this way just to work with architectures without a cmpxchg but with
> xchg ?)

Yes.

Btw, 'git annotate' helps with such questions-to-self sometimes. Because
if you do

$ git annotate include/asm-generic/mutex-xchg.h

you can find the following patch adding __mutex_fastpath_trylock:

commit 620a6fd185c084aa617c411f711533f01ea673c9
Author: Ingo Molnar <mingo@...e.hu>
Date:   Mon Jan 9 15:59:17 2006 -0800

    [PATCH] mutex subsystem, add asm-generic/mutex-[dec|xchg|null].h implementations

    Add three (generic) mutex fastpath implementations.

    The mutex-xchg.h implementation is atomic_xchg() based, and should
    work fine on every architecture.

    The mutex-dec.h implementation is atomic_dec_return() based - this
    one too should work on every architecture, but might not perform the
    most optimally on architectures that have no atomic-dec/inc instructions.

    The mutex-null.h implementation forces all calls into the slowpath. This
    is used for mutex debugging, but it can also be used on platforms that do
    not want (or need) a fastpath at all.

    Signed-off-by: Ingo Molnar <mingo@...e.hu>
    Signed-off-by: Arjan van de Ven <arjan@...radead.org>

HTH.

-- 
Regards/Gruss,
    Boris.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/