From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759023AbcH3SeW (ORCPT ); Tue, 30 Aug 2016 14:34:22 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:34710 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755281AbcH3SeV (ORCPT ); Tue, 30 Aug 2016 14:34:21 -0400 Date: Tue, 30 Aug 2016 20:34:16 +0200 From: Peter Zijlstra To: Oleg Nesterov Cc: Balbir Singh , LKML , Benjamin Herrenschmidt , Nicholas Piggin Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler Message-ID: <20160830183416.GV10138@twins.programming.kicks-ass.net> References: <4050f2ce-1aee-d2aa-39e3-36e995b56252@gmail.com> <20160830121937.GQ10138@twins.programming.kicks-ass.net> <20160830130426.GA17795@redhat.com> <20160830141321.GB2794@worktop> <20160830165746.GA29218@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830165746.GA29218@redhat.com> 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 Tue, Aug 30, 2016 at 06:57:47PM +0200, Oleg Nesterov wrote: > On 08/30, Peter Zijlstra wrote: > > On Tue, Aug 30, 2016 at 03:04:27PM +0200, Oleg Nesterov wrote: > > > But context switch should imply mb() we can rely on? > > > > Not sure it should, on x86 switch_mm does a CR3 write and that is > > serializing, but switch_to() doesn't need to do anything iirc. > > Documentation/memory-barriers.txt says > > schedule() and similar imply full memory barriers. > > and I (wrongly?) interpreted this as if this is also true for 2 > different threadds. I'm not actually sure it does. There is the comment from 8643cda549ca4 which explain the program order guarantees. But I'm not sure who or what would simply a full smp_mb() when you call schedule() -- I mean, its true on x86, but that's 'trivial'. > I mean, I thought that the LOAD/STORE's done by some task can't > be re-ordered with LOAD/STORE's done by another task which was > running on the same CPU. Wrong? If so, I'm not sure how :/ So smp_mb__before_spinlock() stops stores from @prev, and the ACQUIRE from spin_lock(&rq->lock) stops both loads/stores from @next, but afaict nothing stops the loads from @prev seeing stores from @next. Also not sure this matters though, if they're threads in the same process its a data race already and nobody cares. If they're not threads in the same process, they're separated by address space and can't 'see' each other anyway.