From mboxrd@z Thu Jan 1 00:00:00 1970 From: Will Deacon Subject: Re: [PATCH 04/18] alpha: Override READ_ONCE() with barriered implementation Date: Thu, 2 Jul 2020 10:48:33 +0100 Message-ID: <20200702094833.GA16248@willie-the-truck> References: <20200630173734.14057-1-will@kernel.org> <20200630173734.14057-5-will@kernel.org> <20200702093239.GA15391@C02TD0UTHF1T.local> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593683320; bh=8To++DcBmhQUuz2eqkOVWHaWbqWUTZ6jhRKebFqKYqM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pvvSqoKuX6EoQp3iR1pOFMS1VuWVSn9bXK/IVDhTQ1Bb8G4k5KaaptoPD6grev0aX fNdI68lGWQGkuhsT0oBuiB3hXEx9ZLANBXAgOTDc+ixQmjHmi9pG8qTts8l/Xw1PHx R1JOSfYU0SMNZ/OPMRKZNPdqf1Ztg/D9u+MRtgqw= Content-Disposition: inline In-Reply-To: <20200702093239.GA15391@C02TD0UTHF1T.local> Sender: linux-alpha-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Mark Rutland Cc: linux-kernel@vger.kernel.org, Sami Tolvanen , Nick Desaulniers , Kees Cook , Marco Elver , "Paul E. McKenney" , Josh Triplett , Matt Turner , Ivan Kokshaysky , Richard Henderson , Peter Zijlstra , Alan Stern , "Michael S. Tsirkin" , Jason Wang , Arnd Bergmann , Boqun Feng , Catalin Marinas , linux-arm-kernel@lists.infradead.org, linux-alpha@vger.kernel.org, virtualization@lists.linux-foundation.org, kern On Thu, Jul 02, 2020 at 10:32:39AM +0100, Mark Rutland wrote: > On Tue, Jun 30, 2020 at 06:37:20PM +0100, Will Deacon wrote: > > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > > +#define __smp_load_acquire(p) \ > > +({ \ > > + __unqual_scalar_typeof(*p) ___p1 = \ > > + (*(volatile typeof(___p1) *)(p)); \ > > + compiletime_assert_atomic_type(*p); \ > > + ___p1; \ > > +}) > > Sorry if I'm being thick, but doesn't this need a barrier after the > volatile access to provide the acquire semantic? > > IIUC prior to this commit alpha would have used the asm-generic > __smp_load_acquire, i.e. > > | #ifndef __smp_load_acquire > | #define __smp_load_acquire(p) \ > | ({ \ > | __unqual_scalar_typeof(*p) ___p1 = READ_ONCE(*p); \ > | compiletime_assert_atomic_type(*p); \ > | __smp_mb(); \ > | (typeof(*p))___p1; \ > | }) > | #endif > > ... where the __smp_mb() would be alpha's mb() from earlier in the patch > context, i.e. > > | #define mb() __asm__ __volatile__("mb": : :"memory") > > ... so don't we need similar before returning ___p1 above in > __smp_load_acquire() (and also matching the old read_barrier_depends())? > > [...] > > > +#include > > + > > +/* > > + * Alpha is apparently daft enough to reorder address-dependent loads > > + * on some CPU implementations. Knock some common sense into it with > > + * a memory barrier in READ_ONCE(). > > + */ > > +#define __READ_ONCE(x) __smp_load_acquire(&(x)) > > As above, I don't see a memory barrier implied here, so this doesn't > look quite right. You're right, and Peter spotted the same thing off-list. I've reworked locally so that the mb() ends up in __READ_ONCE() and __smp_load_acquire() calles __READ_ONCE() instead of the other way round (which made more sense before the rework in the merge window). Will