Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 3 Jun 2019 14:42:00 +0800
From:   Boqun Feng <boqun.feng@gmail.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     "Paul E. McKenney" <paulmck@linux.ibm.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Netdev <netdev@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>
Subject: Re: rcu_read_lock lost its compiler barrier
Message-ID: <20190603064200.GA11024@tardis>
References: <20150910102513.GA1677@fixme-laptop.cn.ibm.com>
 <20150910171649.GE4029@linux.vnet.ibm.com>
 <20150911021933.GA1521@fixme-laptop.cn.ibm.com>
 <20150921193045.GA13674@lerouge>
 <20150921204327.GH4029@linux.vnet.ibm.com>
 <20190602055607.bk5vgmwjvvt4wejd@gondor.apana.org.au>
 <CAHk-=whLGKOmM++OQi5GX08_dfh8Xfz9Wq7khPo+MVtPYh_8hw@mail.gmail.com>
 <20190603024640.2soysu4rpkwjuash@gondor.apana.org.au>
 <20190603034707.GG28207@linux.ibm.com>
 <20190603052626.nz2qktwmkswxfnsd@gondor.apana.org.au>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd"
Content-Disposition: inline
In-Reply-To: <20190603052626.nz2qktwmkswxfnsd@gondor.apana.org.au>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--ADZbWkCsHQ7r3kzd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 03, 2019 at 01:26:26PM +0800, Herbert Xu wrote:
> On Sun, Jun 02, 2019 at 08:47:07PM -0700, Paul E. McKenney wrote:
> >=20
> > 1.	These guarantees are of full memory barriers, -not- compiler
> > 	barriers.
>=20
> What I'm saying is that wherever they are, they must come with
> compiler barriers.  I'm not aware of any synchronisation mechanism
> in the kernel that gives a memory barrier without a compiler barrier.
>=20
> > 2.	These rules don't say exactly where these full memory barriers
> > 	go.  SRCU is at one extreme, placing those full barriers in
> > 	srcu_read_lock() and srcu_read_unlock(), and !PREEMPT Tree RCU
> > 	at the other, placing these barriers entirely within the callback
> > 	queueing/invocation, grace-period computation, and the scheduler.
> > 	Preemptible Tree RCU is in the middle, with rcu_read_unlock()
> > 	sometimes including a full memory barrier, but other times with
> > 	the full memory barrier being confined as it is with !PREEMPT
> > 	Tree RCU.
>=20
> The rules do say that the (full) memory barrier must precede any
> RCU read-side that occur after the synchronize_rcu and after the
> end of any RCU read-side that occur before the synchronize_rcu.
>=20
> All I'm arguing is that wherever that full mb is, as long as it
> also carries with it a barrier() (which it must do if it's done
> using an existing kernel mb/locking primitive), then we're fine.
>=20
> > Interleaving and inserting full memory barriers as per the rules above:
> >=20
> > 	CPU1: WRITE_ONCE(a, 1)
> > 	CPU1: synchronize_rcu=09
> > 	/* Could put a full memory barrier here, but it wouldn't help. */
>=20
> 	CPU1: smp_mb();
> 	CPU2: smp_mb();
>=20
> Let's put them in because I think they are critical.  smp_mb() also
> carries with it a barrier().
>=20
> > 	CPU2: rcu_read_lock();
> > 	CPU1: b =3D 2;=09
> > 	CPU2: if (READ_ONCE(a) =3D=3D 0)
> > 	CPU2:         if (b !=3D 1)  /* Weakly ordered CPU moved this up! */
> > 	CPU2:                 b =3D 1;
> > 	CPU2: rcu_read_unlock
> >=20
> > In fact, CPU2's load from b might be moved up to race with CPU1's store,
> > which (I believe) is why the model complains in this case.
>=20
> Let's put aside my doubt over how we're even allowing a compiler
> to turn
>=20
> 	b =3D 1
>=20
> into
>=20
> 	if (b !=3D 1)
> 		b =3D 1
>=20
> Since you seem to be assuming that (a =3D=3D 0) is true in this case

I think Paul's example assuming (a =3D=3D 0) is false, and maybe
speculative writes (by compilers) needs to added into consideration?
Please consider the following case (I add a few smp_mb()s), the case may
be a little bit crasy, you have been warned ;-)

 	CPU1: WRITE_ONCE(a, 1)
 	CPU1: synchronize_rcu called

 	CPU1: smp_mb(); /* let assume there is one here */

 	CPU2: rcu_read_lock();
 	CPU2: smp_mb(); /* let assume there is one here */

	/* "if (b !=3D 1) b =3D 1" reordered  */
 	CPU2: r0 =3D b;       /* if (b !=3D 1) reordered here, r0 =3D=3D 0 */
 	CPU2: if (r0 !=3D 1)  /* true */
	CPU2:     b =3D 1;    /* b =3D=3D 1 now, this is a speculative write
	                       by compiler
			     */

	CPU1: b =3D 2;        /* b =3D=3D 2 */

 	CPU2: if (READ_ONCE(a) =3D=3D 0) /* false */
	CPU2: ...
	CPU2  else                   /* undo the speculative write */
	CPU2:	  b =3D r0;   /* b =3D=3D 0 */

 	CPU2: smp_mb();
	CPU2: read_read_unlock();

I know this is too crasy for us to think a compiler like this, but this
might be the reason why the model complain about this.

Paul, did I get this right? Or you mean something else?

Regards,
Boqun


> (as the assignment b =3D 1 is carried out), then because of the
> presence of the full memory barrier, the RCU read-side section
> must have started prior to the synchronize_rcu.  This means that
> synchronize_rcu is not allowed to return until at least the end
> of the grace period, or at least until the end of rcu_read_unlock.
>=20
> So it actually should be:
>=20
> 	CPU1: WRITE_ONCE(a, 1)
> 	CPU1: synchronize_rcu called
> 	/* Could put a full memory barrier here, but it wouldn't help. */
>=20
> 	CPU1: smp_mb();
> 	CPU2: smp_mb();
>=20
> 	CPU2: grace period starts
> 	...time passes...
> 	CPU2: rcu_read_lock();
> 	CPU2: if (READ_ONCE(a) =3D=3D 0)
> 	CPU2:         if (b !=3D 1)  /* Weakly ordered CPU moved this up! */
> 	CPU2:                 b =3D 1;
> 	CPU2: rcu_read_unlock
> 	...time passes...
> 	CPU2: grace period ends
>=20
> 	/* This full memory barrier is also guaranteed by RCU. */
> 	CPU2: smp_mb();
>=20
> 	CPU1 synchronize_rcu returns
> 	CPU1: b =3D 2;=09
>=20
> Cheers,
> --=20
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

--ADZbWkCsHQ7r3kzd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAlz0wTUACgkQSXnow7UH
+rhlUQf/fOWYt2sawXloMg9SKEFA08dot6GWx7MXYzpYQIX1Zp8RxcALCVVWP0CD
rBexn6JFN99VDhMYU48f2ZRs6dk0YAHAVJpqnAXBJDBARdxwbViB8GdD/seu+3hC
HBFeOXZVtqw303lZtF2Gia8+1M01XwuR3YV/BB8TSsD7FYZPMQx1NIBtQJ2IrHIF
G58qsbB7+4H7LLCJCjSb+mUyekt5HGZguhZL+ib3kbPsEY0yoZ9S3hqqQ14OTPFG
yyerP0RXMKbhqNEJxNnkusIYiiaybwMbLYI+r/mzZkEcTEzGfeRqeoNHzsJKJr82
vTSY45HAtRjhjasbi3g9HcKbWhoF5g==
=l2S9
-----END PGP SIGNATURE-----

--ADZbWkCsHQ7r3kzd--