From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933976AbcIAOR4 (ORCPT ); Thu, 1 Sep 2016 10:17:56 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:34326 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933918AbcIAORp (ORCPT ); Thu, 1 Sep 2016 10:17:45 -0400 Date: Thu, 1 Sep 2016 22:17:57 +0800 From: Boqun Feng To: Peter Zijlstra Cc: Benjamin Herrenschmidt , Oleg Nesterov , Balbir Singh , LKML , Nicholas Piggin Subject: Re: [RFC][PATCH] Fix a race between rwsem and the scheduler Message-ID: <20160901141757.GA24098@tardis.cn.ibm.com> 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> <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20160901065738.GH10153@twins.programming.kicks-ass.net> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 01, 2016 at 08:57:38AM +0200, Peter Zijlstra wrote: > On Thu, Sep 01, 2016 at 07:47:10AM +1000, Benjamin Herrenschmidt wrote: >=20 > > > OK, for giggles, could you (or Balbir) check what happens if you take > > > that sync out? >=20 > > The problem is no amount of testing can tell you it works for sure :-) >=20 > It breaking does prove the negative though, so still interesting. >=20 > > I would be nervous not having a real full sync in _switch. All we have > > along the scheduler path is lwsync's and our isync based load construct > > for spin_lock, I'm not sure what other assumptions we have around that > > sync in there... >=20 > Only one way to find out ;-) >=20 > I'm not saying you should commit that change, just curious if (and how > fast) it would come apart. >=20 > At the very least we could update the comment that goes with that sync. Could there be some code that relies on the full barrier semantics of schedule() to provide transitivity? IIUC, the Program Order Guarantee you stated before try_to_wake_up() only has ordering effect on wakers and wakees. Regards, Boqun --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXyDiSAAoJEEl56MO1B/q4LN4H/ieWvzE5rgoqSMcWL8A9ZMmL TCbrlBupEMUOe/5k2OIVuiMeluBNQbES1nMeqRCH+i2Ci4c3PUHlTekko45+TQ82 Q9K/O+Wo2THWYTXeDC4yBg1Hm9STIOAxVjK6Sm07Diui4ryH4YLlX4p5YCLsrwCb CSnZrD8sG9FPyGS94CqZIBnHY6tL1TSKSuC4JNcb4Zld7/aPjGagLHS7ZERg61WH ReqCk11baLSIy1GZrQEvNSw+zkWV4BLQUtztqVEu0Y+c10RUw2xnq11LNFihsVTf b1Gn5I9uSmTTSS4EgFyJT/I625Tshg1TxD+j+e/I3mABWAt5Cy5xC/2kr5mvpK8= =ORgy -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--