From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755416AbdCGOar (ORCPT ); Tue, 7 Mar 2017 09:30:47 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:35718 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752573AbdCGOaj (ORCPT ); Tue, 7 Mar 2017 09:30:39 -0500 Date: Tue, 7 Mar 2017 22:27:40 +0800 From: Boqun Feng To: Dmitry Vyukov Cc: Paul McKenney , josh@joshtriplett.org, Steven Rostedt , Mathieu Desnoyers , jiangshanlai@gmail.com, LKML , syzkaller Subject: Re: rcu: WARNING in rcu_seq_end Message-ID: <20170307142740.uh2nnaw44albn3t2@tardis> References: <20170304204052.GC30506@linux.vnet.ibm.com> <20170305184736.GD30506@linux.vnet.ibm.com> <20170306100741.GJ30506@linux.vnet.ibm.com> <20170306230800.GK30506@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dcbyclgzql7onkj4" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170225 (1.8.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --dcbyclgzql7onkj4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 07, 2017 at 08:05:19AM +0100, Dmitry Vyukov wrote: [...] > >> > >> What is that mutex? And what locks/unlocks provide synchronization? I > >> see that one uses exp_mutex and another -- exp_wake_mutex. > > > > Both of them. > > > > ->exp_mutex is acquired by the task requesting the grace period, and > > the counter's first increment is done by that task under that mutex. > > This task then schedules a workqueue, which drives forward the grace > > period. Upon grace-period completion, the workqueue handler does the > > second increment (the one that your patch addressed). The workqueue > > handler then acquires ->exp_wake_mutex and wakes the task that holds > > ->exp_mutex (along with all other tasks waiting for this grace period), > > and that task releases ->exp_mutex, which allows the next grace period = to > > start (and the first increment for that next grace period to be carried > > out under that lock). The workqueue handler releases ->exp_wake_mutex > > after finishing its wakeups. >=20 >=20 > Then we need the following for the case when task requesting the grace > period does not block, right? >=20 Won't be necessary I think, as the smp_mb() in rcu_seq_end() and the smp_mb__before_atomic() in sync_exp_work_done() already provide the required ordering, no? Regards, Boqun > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index d80c2587bed8..aa7ba83f6a56 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -3534,7 +3534,7 @@ static void rcu_seq_start(unsigned long *sp) > static void rcu_seq_end(unsigned long *sp) > { > smp_mb(); /* Ensure update-side operation before counter incremen= t. */ > - WRITE_ONCE(*sp, *sp + 1); > + smp_store_release(sp, *sp + 1); > WARN_ON_ONCE(*sp & 0x1); > } >=20 > @@ -3554,7 +3554,7 @@ static unsigned long rcu_seq_snap(unsigned long *sp) > */ > static bool rcu_seq_done(unsigned long *sp, unsigned long s) > { > - return ULONG_CMP_GE(READ_ONCE(*sp), s); > + return ULONG_CMP_GE(smp_load_acquire(sp), s); >=20 > } --dcbyclgzql7onkj4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEj5IosQTPz8XU1wRHSXnow7UH+rgFAli+w1gACgkQSXnow7UH +riGIAf/SYyyFYswKhRiRLrRfbPhktur54HSuR2PYmWQUO8XKIJxKS3dOT+q41Bl D2uhRRxQ1ohiMIw2e4b0VQYRKn2LvRsLj2f61x44yxdVA74FylKhCe7V/WEIvbsp l2LSMNxLf8FG9htTKAKRvN2I9S2FJVPWE5ovmrp1NrAEhpWpPJbMPpKD7oXd2i49 0tRaIWS+G1hLVnGrK8kFblJYySO/8/Y04iD7K8IOf/7ah7VRWLgy+XFXwfi2qNwN W0MY1JyanEyZZ2UTtSwQz6zt/Rw5pcDNKrF5TdtWiJfmaI0rQcMZKI0RB3ObgKe3 bPvRwDtSjKWcGkwQvY8Y/m+DwyceKw== =Gt80 -----END PGP SIGNATURE----- --dcbyclgzql7onkj4--