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 S934068AbcIAPdn (ORCPT <rfc822;w@1wt.eu>);
        Thu, 1 Sep 2016 11:33:43 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:49032 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S933138AbcIAPdh (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 1 Sep 2016 11:33:37 -0400
Date: Thu, 1 Sep 2016 17:33:10 +0200
From: Peter Zijlstra <peterz@infradead.org>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Oleg Nesterov <oleg@redhat.com>, Balbir Singh <bsingharora@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Nicholas Piggin <nicholas.piggin@gmail.com>
Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler
Message-ID: <20160901153310.GW10153@twins.programming.kicks-ass.net>
References: <20160830121937.GQ10138@twins.programming.kicks-ass.net>
 <20160830130426.GA17795@redhat.com>
 <20160830141321.GB2794@worktop>
 <20160830165746.GA29218@redhat.com>
 <20160830183416.GV10138@twins.programming.kicks-ass.net>
 <1472592498.2388.40.camel@kernel.crashing.org>
 <20160831133104.GD10153@twins.programming.kicks-ass.net>
 <1472680030.2388.95.camel@kernel.crashing.org>
 <20160901065738.GH10153@twins.programming.kicks-ass.net>
 <20160901141757.GA24098@tardis.cn.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160901141757.GA24098@tardis.cn.ibm.com>
User-Agent: Mutt/1.5.23.1 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Sep 01, 2016 at 10:17:57PM +0800, Boqun Feng wrote:
> On Thu, Sep 01, 2016 at 08:57:38AM +0200, Peter Zijlstra wrote:
> Could there be some code that relies on the full barrier semantics of
> schedule() to provide transitivity?

Could, sure, who knows. RCU might, although Paul typically sticks in
smp_mb just to be safe.

The kernel coming apart when you remove that sync would prove this
fairly quick though.

Like Ben said, it not coming apart doesn't prove anything. It coming
apart does however prove something, namely that it is required :-)

> IIUC, the Program Order Guarantee you stated before try_to_wake_up()
> only has ordering effect on wakers and wakees.

Right, the scheduler only does RCpc guarantees.