From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758427AbcH3Q6W (ORCPT ); Tue, 30 Aug 2016 12:58:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52482 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758064AbcH3Q6V (ORCPT ); Tue, 30 Aug 2016 12:58:21 -0400 Date: Tue, 30 Aug 2016 18:57:47 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: Balbir Singh , LKML , Benjamin Herrenschmidt , Nicholas Piggin Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler Message-ID: <20160830165746.GA29218@redhat.com> References: <4050f2ce-1aee-d2aa-39e3-36e995b56252@gmail.com> <20160830121937.GQ10138@twins.programming.kicks-ass.net> <20160830130426.GA17795@redhat.com> <20160830141321.GB2794@worktop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160830141321.GB2794@worktop> User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 30 Aug 2016 16:58:20 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/30, Peter Zijlstra wrote: > On Tue, Aug 30, 2016 at 03:04:27PM +0200, Oleg Nesterov wrote: > > On 08/30, Peter Zijlstra wrote: > > > > > > /* > > > * Ensure we load p->on_rq _after_ p->state, otherwise it would > > > * be possible to, falsely, observe p->on_rq == 0 and get stuck > > > * in smp_cond_load_acquire() below. > > > * > > > * sched_ttwu_pending() try_to_wake_up() > > > * [S] p->on_rq = 1; [L] P->state > > > * UNLOCK rq->lock > > > * > > > * schedule() RMB > > > * LOCK rq->lock > > > * UNLOCK rq->lock > > > * > > > * [task p] > > > * [S] p->state = UNINTERRUPTIBLE [L] p->on_rq > > > * > > > * Pairs with the UNLOCK+LOCK on rq->lock from the > > > * last wakeup of our task and the schedule that got our task > > > * current. > > > */ > > > > Confused... how this connects to UNLOCK+LOCK on rq->lock? A LOAD can > > leak into the critical section. > > How so? That LOCK+UNLOCK which is leaky, UNLOCK+LOCK is a read/write > barrier (just not an MB because it lacks full transitivity). Ah, I have wrongly read the "Pairs with the UNLOCK+LOCK" as "Pairs with the LOCK+UNLOCK". And didn't notice this even after I copy-and-pasted this part. > > 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 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? Oleg.