From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932737AbbJPQjY (ORCPT <rfc822;w@1wt.eu>);
	Fri, 16 Oct 2015 12:39:24 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:38555 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932123AbbJPQjX (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 16 Oct 2015 12:39:23 -0400
Date: Fri, 16 Oct 2015 18:39:15 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org,
        Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: Q: schedule() and implied barriers on arm64
Message-ID: <20151016163915.GB3816@twins.programming.kicks-ass.net>
References: <20151016151830.GZ3816@twins.programming.kicks-ass.net>
 <20151016160422.GQ3910@linux.vnet.ibm.com>
 <20151016161608.GA3816@twins.programming.kicks-ass.net>
 <20151016162824.GS3910@linux.vnet.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151016162824.GS3910@linux.vnet.ibm.com>
User-Agent: Mutt/1.5.21 (2012-12-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Oct 16, 2015 at 09:28:24AM -0700, Paul E. McKenney wrote:

> > Maybe some previous RCU variant relied on this?
> 
> Yes, older versions did rely on this.  Now, only the CPU itself observes
> RCU's state changes during context switch.  I couldn't tell you exactly
> when this changed.  :-/
> 
> With the exception of some synchronize_sched_expedited() cases, but in
> those cases, RCU code acquires the CPU's leaf rcu_node structure's
> ->lock, and with the required strong transitivity.

OK, so I can scrap this 'requirement' from my list. All sorted, thanks!

> > > Well, arm64 might well need smp_mb__after_unlock_lock() to be non-empty.
> > 
> > Its UNLOCK+LOCK should be RCsc, so that should be good. Its just that
> > LOCK+UNLOCK isn't anything.
> 
> Ah!  If RCU relies on LOCK+UNLOCK being a barrier of any sort, that is a
> bug in RCU that needs fixing.

Don't think RCU does that, But its what schedule() provides in the
weakest case. Hence my question here.