From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754722AbbKLOtd (ORCPT ); Thu, 12 Nov 2015 09:49:33 -0500 Received: from mail-pa0-f65.google.com ([209.85.220.65]:34378 "EHLO mail-pa0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752805AbbKLOtc (ORCPT ); Thu, 12 Nov 2015 09:49:32 -0500 Date: Thu, 12 Nov 2015 22:49:02 +0800 From: Boqun Feng To: "Paul E. McKenney" Cc: Oleg Nesterov , Peter Zijlstra , mingo@kernel.org, linux-kernel@vger.kernel.org, corbet@lwn.net, mhocko@kernel.org, dhowells@redhat.com, torvalds@linux-foundation.org, will.deacon@arm.com, Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras Subject: Re: [PATCH 4/4] locking: Introduce smp_cond_acquire() Message-ID: <20151112144902.GA4549@fixme-laptop.cn.ibm.com> References: <20151102132901.157178466@infradead.org> <20151102134941.005198372@infradead.org> <20151103175958.GA4800@redhat.com> <20151111093939.GA6314@fixme-laptop.cn.ibm.com> <20151111121232.GN17308@twins.programming.kicks-ass.net> <20151111193953.GA23515@redhat.com> <20151112070915.GC6314@fixme-laptop.cn.ibm.com> <20151112150058.GA30321@redhat.com> <20151112144004.GU3972@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20151112144004.GU3972@linux.vnet.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 12, 2015 at 06:40:04AM -0800, Paul E. McKenney wrote: [snip] >=20 > I cannot resist suggesting that any lock that interacts with > spin_unlock_wait() must have all relevant acquisitions followed by > smp_mb__after_unlock_lock(). >=20 But 1. This would expand the purpose of smp_mb__after_unlock_lock(), right? smp_mb__after_unlock_lock() is for making UNLOCK-LOCK pair global transitive rather than guaranteeing no operations can be reorder before the STORE part of LOCK/ACQUIRE. 2. If ARM64 has the same problem as PPC now, smp_mb__after_unlock_lock() can't help, as it's a no-op on ARM64. Regards, Boqun --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWRKbaAAoJEEl56MO1B/q44OAH/2GpHgarCY9bEY0MrlQ/jb13 k1w7nTSBYCX6FS92uMOmg0loCq708IQ7Nee1zEuebXDHoN5UGLoDsLqZb/ylzRqv EQbLfMZInZiT4GMTCdzXw3tXsLWfPnVRlMky5g3+taAvJhAtJm2eHLUjyk8iFzXI anIv/n4fqcml8B9UpKPLjg40pyGMUceYtSajDaTJAQay7KUfJfC4mt9MVqZF9Cyz z8NEQiJ8ksgKufeD3in7MTZpIfPfOE1XwrSfZJAFwKH8H65FIsVOc1iGR2qwIQxB Xd/BRFcm5AVUSQ14nAHx3nG993P2Mmj/jHFFbqOI3y9qAjO/seDeROtIgEwHYCc= =ysqA -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e--