From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754696AbbL3Wog (ORCPT ); Wed, 30 Dec 2015 17:44:36 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:55795 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750904AbbL3Woc (ORCPT ); Wed, 30 Dec 2015 17:44:32 -0500 From: Arnd Bergmann To: "Michael S. Tsirkin" Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , linux-arch@vger.kernel.org, Andrew Cooper , virtualization@lists.linux-foundation.org, Stefano Stabellini , Davidlohr Bueso , Ingo Molnar Subject: Re: [PATCH 08/34] asm-generic: smp_store_mb should use smp_mb Date: Wed, 30 Dec 2015 23:43:29 +0100 Message-ID: <1735310.18sBYE1ZVH@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151230222703-mutt-send-email-mst@redhat.com> References: <1451473761-30019-1-git-send-email-mst@redhat.com> <5946017.BCmPrpGMuh@wuerfel> <20151230222703-mutt-send-email-mst@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:/qSSMPF5VInXo+M2ysVMbrl26fqeR3YhPd2CSMkwitrzfN4dFE5 MhWaTW+VpBbGp3FmJHIPwsyYOGFiVqMh+A5FJj9Crkqak3G9Mwo9zFAkazYwA1JWsqEpi0U kDciPeTxYcaf60shrdnr/T5X4SjEhCSgziL+xnPQjncwM18i9JMRJiS9pHmcphe/vWcikSu ZlKa77L8k18RfUp9b+LBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:1hgzYG59pBo=:bglgV3HAAAAKm3P233Ui/p 7/H2JhJ3NIZnFXRbasSGbN7FoNswJaM/urgLCBOyxVIDyOvq41dMWfzC3dtd0afayUQ6PoVKv SevLhc9FqN1exIXBoFTF/IO3f2GKzhuL3geANR2jI8AC8SVvZBzblJ6WbeQyue0YR3sV1W8gQ PwYyHU7+GuW/Zy1Gsx5BgSUGD5/Jm9vaBQiKDKB5Y4xd6Zlt7XqReLZv6Lxhg9x+hz0J+L0pA Q5sb05PqLDPM58jQYN2UpPx+ofdYCIM9dQ3tzW+hfj6b47nwbI15H9W2RHI+3cnQpT9j1j0TI iqUCQ+3CogozBwFJxInMzjgCPe6Zv1F9ZFyFODXJqPH9TAYx5O8lUeaMz1wQLN/Dv1onk4MDg sR/QswSDkWE4jXbwOvVgqCc6eerwT9MHbSM53nMdHXObZRxd3tm5HI+e5l90BQeud4CBkL/AV OEljEdussmzBdXPxS6uQJ4D+lrg4rTy1hcySLDtVBLVnZB4oee5EuTMep0HK1SGe7WyaE8t8U 8T+qqyi5q2pEaKrKeq59JfOZS6q5XffmyWgPub86Nwo7AMNOv3OqK8JpQNS4QRlTYEOh4Acck Cl0/5eLwoetMqqBeQ+xdeFLpvVQ+pY6XropecTSwbY+VrhqOTvBAwkUDR4B5Oh5dthtKW80xA YJYpO/poNcNxKn3YuFYsS9shPW0S9H6sTjtxFQTtbMNPEDgzqqjidKiOJEmZUvVqc7esfwSLq 5HiHugWZTu/N6Wcw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 30 December 2015 22:30:38 Michael S. Tsirkin wrote: > On Wed, Dec 30, 2015 at 02:44:21PM +0100, Arnd Bergmann wrote: > > On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > > > #ifndef smp_store_mb > > > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > > > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > > #endif > > > > > > #ifndef smp_mb__before_atomic > > > > > > > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd > > ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). > > Sorry which tree do you mean exactly? $ git log --ancestry-path --oneline --merges d5a73cadf3fd..next/master | tail -n 17 cb17a685bed6 Merge remote-tracking branch 'tip/auto-latest' f29c2e03f0b3 Merge branch 'x86/urgent' 8cd6990bf71d Merge branch 'x86/platform' 0541d92a5eb4 Merge branch 'x86/mm' aa7c8013c8c0 Merge branch 'x86/fpu' fcc9a1bd013c Merge branch 'x86/efi' e74ef3f60886 Merge branch 'x86/cpu' 44a4f0063508 Merge branch 'x86/cleanups' 28c814578fcf Merge branch 'x86/cache' d74ff99dada8 Merge branch 'x86/boot' db3c55380b10 Merge branch 'x86/asm' 7cd91b91da20 Merge branch 'x86/apic' 7bfc343947e6 Merge branch 'timers/core' 1720bbcb66d1 Merge branch 'sched/core' af9a59f26764 Merge branch 'ras/core' 984b85eca78d Merge branch 'perf/core' d2b22d438aab Merge branch 'locking/core' $ grep auto-latest Next/Trees tip git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git#auto-latest So locking/core of tip.git has the patch and gets merged into linux-next through auto-latest in tip.git. > > I think you can drop your version. > > > > arnd > > Will drop mine, thanks. > I kind of dislike that if I just drop it, some arches will temporarily > regress to a slower implementation. > I think I can just cherry-pick d5a73cadf3fd into my tree: git > normally figures such duplicates out nicely. > Does this sound good? I don't think there is a perfect solution, you can either cherry-pick it and get a duplicate commit in the git history, or you merge in the whole locking/core branch from tip. I'd say ask Ingo/PeterZ/Davidlohr which way they prefer. Arnd