linux-kernel - How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt?

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

Date:	Fri, 22 Mar 2013 19:58:45 +0800
From:	Zhu Yanhai <zhu.yanhai@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Richard Weinberger <richard@....at>,
	Jan Beulich <jbeulich@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
	muming.wq@...bao.com
Subject: How does spin_unlock() in x86-64 align with the description in Documention/memory-barriers.txt?

Hi all,
In the documention it reads,

(2) UNLOCK operation implication:

     Memory operations issued before the UNLOCK will be completed before the
     UNLOCK operation has completed.

     Memory operations issued after the UNLOCK may be completed before the
     UNLOCK operation has completed.

However, on x86-64 __ticket_spin_unlock() merely does,

static __always_inline void __ticket_spin_unlock(raw_spinlock_t *lock)
{
    asm volatile(
        ALTERNATIVE(UNLOCK_LOCK_PREFIX"incb (%0);"ASM_NOP3,
                UNLOCK_LOCK_ALT_PREFIX"movw $0, (%0)",
                X86_FEATURE_UNFAIR_SPINLOCK)
        :
        : "Q" (&lock->slock)
        : "memory", "cc");
}

While both UNLOCK_LOCK_PREFIX and UNLOCK_LOCK_ALT_PREFIX are empty
strings. So how such a function keeps the memory operations issued
before it completed?

--
Thanks,
Zhu Yanhai
--
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/