From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753625AbcIBWOV (ORCPT ); Fri, 2 Sep 2016 18:14:21 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52966 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753207AbcIBWOT (ORCPT ); Fri, 2 Sep 2016 18:14:19 -0400 Date: Sat, 3 Sep 2016 00:14:13 +0200 From: Peter Zijlstra To: Alan Stern Cc: "Paul E. McKenney" , Ingo Molnar , Felipe Balbi , USB list , Kernel development list Subject: Re: Memory barrier needed with wake_up_process()? Message-ID: <20160902221413.GN10153@twins.programming.kicks-ass.net> References: <20160902191857.GL10153@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 02, 2016 at 04:16:54PM -0400, Alan Stern wrote: > > Actually, that's not entirely true (although presumably it works okay > for most architectures). Yeah, all load-store archs (with exception of PowerPC and ARM64 and possibly MIPS) implement ACQUIRE with a general fence (after the ll/sc). ( and MIPS doesn't use their fancy barriers in Linux ) PowerPC does the full fence for smp_mb__before_spinlock, which leaves ARM64, I'm not sure its correct, but I'm way too tired to think about that now. The TSO archs imply full barriers with all atomic RmW ops and are therefore also good.