linux-kernel - Re: [PATCH v5 4/4] MCS Lock: Barrier corrections

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

Message-ID: <20131112171633.7498.qmail@science.horizon.com>
Date:	12 Nov 2013 12:16:33 -0500
From:	"George Spelvin" <linux@...izon.com>
To:	tim.c.chen@...ux.intel.com, will.deacon@....com
Cc:	a.p.zijlstra@...llo.nl, aarcange@...hat.com,
	akpm@...ux-foundation.org, alex.shi@...aro.org,
	andi@...stfloor.org, arnd@...db.de, aswin@...com,
	dave.hansen@...el.com, davidlohr.bueso@...com, figo1802@...il.com,
	hpa@...or.com, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	linux@...izon.com, matthew.r.wilcox@...el.com, mingo@...e.hu,
	paulmck@...ux.vnet.ibm.com, peter@...leysoftware.com,
	raghavendra.kt@...ux.vnet.ibm.com, riel@...hat.com,
	scott.norton@...com, tglx@...utronix.de,
	torvalds@...ux-foundation.org, waiman.long@...com,
	walken@...gle.com
Subject: Re: [PATCH v5 4/4] MCS Lock: Barrier corrections

> On Mon, Nov 11, 2013 at 09:17:52PM +0000, Tim Chen wrote:
>> An alternate implementation is
>> 	while (!ACCESS_ONCE(node->locked))
>> 		arch_mutex_cpu_relax();
>> 	smp_load_acquire(&node->locked);
>> 
>> Leaving the smp_load_acquire at the end to provide appropriate barrier.
>> Will that be acceptable?

Will Deacon <will.deacon@....com> wrote:
> It still doesn't solve my problem though: I want a way to avoid that busy
> loop by some architecture-specific manner. The arch_mutex_cpu_relax() hook
> is a start, but there is no corresponding hook on the unlock side to issue a
> wakeup. Given a sensible relax implementation, I don't have an issue with
> putting a load-acquire in a loop, since it shouldn't be aggresively spinning
> anymore.

So you want something like this?

/*
 * This is a spin-wait with acquire semantics.  That is, accesses after
 * this are not allowed to be reordered before the load that meets
 * the specified condition.  This requires that it end with either a
 * load-acquire or a full smp_mb().  The optimal way to do this is likely
 * to be architecture-dependent.  E.g. x86 MONITOR/MWAIT instructions.
 */
#ifndef smp_load_acquire_until
#define smp_load_acquire_until(addr, cond) \
	while (!(smp_load_acquire(addr) cond)) { \
		do { \
			arch_mutex_cpu_relax(); \
		} while (!(ACCESS_ONCE(*(addr)) cond)); \
	}
#endif

	smp_load_acquire_until(&node->locked, != 0);

Alternative implementations:

#define smp_load_acquire_until(addr, cond) { \
	while (!(ACCESS_ONCE(*(addr)) cond)) \
		arch_mutex_cpu_relax(); \
	smp_mb(); }

#define smp_load_acquire_until(addr, cond) \
	if (!(smp_load_acquire(addr) cond)) { \
		do { \
			arch_mutex_cpu_relax(); \
		} while (!(ACCESS_ONCE(*(addr)) cond)); \
		smp_mb(); \
	}
--
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/