From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754074AbcBBITH (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Feb 2016 03:19:07 -0500
Received: from mail-ig0-f177.google.com ([209.85.213.177]:33979 "EHLO
	mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753912AbcBBITF (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Feb 2016 03:19:05 -0500
MIME-Version: 1.0
In-Reply-To: <CA+55aFyrZZYKK4hsRX6GTuJ0vxJ6uyVgb2i8mMuMoKE4JoS+jQ@mail.gmail.com>
References: <20160127145421.GT6357@twins.programming.kicks-ass.net>
	<20160127152158.GJ2390@arm.com>
	<20160127233836.GQ4503@linux.vnet.ibm.com>
	<20160128095718.GC30928@arm.com>
	<20160128223131.GV4503@linux.vnet.ibm.com>
	<20160129095958.GA4541@arm.com>
	<20160129102253.GG4503@linux.vnet.ibm.com>
	<20160201135621.GD6828@arm.com>
	<20160202035458.GF6719@linux.vnet.ibm.com>
	<20160202051904.GC1239@fixme-laptop.cn.ibm.com>
	<20160202064433.GG6719@linux.vnet.ibm.com>
	<CA+55aFyrZZYKK4hsRX6GTuJ0vxJ6uyVgb2i8mMuMoKE4JoS+jQ@mail.gmail.com>
Date: Tue, 2 Feb 2016 00:19:04 -0800
X-Google-Sender-Auth: yg2g40ZsQDyFbTQt7KxVDHsxJLQ
Message-ID: <CA+55aFwQ07x1ngSUEqqe7_6Kz2pY2+8rT5zamrQfubQhgHDKBw@mail.gmail.com>
Subject: Re: [RFC][PATCH] mips: Fix arch_spin_unlock()
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Paul McKenney <paulmck@linux.vnet.ibm.com>
Cc: Boqun Feng <boqun.feng@gmail.com>, Will Deacon <will.deacon@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "Maciej W. Rozycki" <macro@imgtec.com>,
        David Daney <ddaney@caviumnetworks.com>,
        =?UTF-8?B?TcOlbnMgUnVsbGfDpXJk?= <mans@mansr.com>,
        Ralf Baechle <ralf@linux-mips.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Feb 2, 2016 at 12:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So we *absolutely* should say that *OF COURSE* these things work:
>
>  - CPU A:
>
>    .. initialize data structure -> smp_wmb() -> WRITE_ONCE(ptr);
>
>  - CPU B:
>
>    smp_load_acquire(ptr)  - we can rely on things behind "ptr" being initialized

That's a bad example, btw. I shouldn't have made it be a "pointer",
because then we get the whole address dependency chain ordering
anyway.

So instead of "ptr", read "state flag". It might just be an "int" that
says "data has been initialized".

So

    .. initialize memory ..
    smp_wmb();
    WRITE_ONCE(&is_initialized, 1);

should pair with

    if (smp_load_acquire(&is_initialized))
        ... we can read and write the data, knowing it has been initialized ..

exactly because "smp_wmb()" (cheap write barrier) might be cheaper
than "smp_store_release()" (expensive full barrier) and thus
preferred.

So mixing ordering metaphors actually does make sense, and should be
entirely well-defined.

There's likely less reason to do it the other way (ie
"smp_store_release()" on one side pairing with "LOAD_ONCE() +
smp_rmb()" on the other) since there likely isn't the same kind of
performance reason for that pairing. But even if we would never
necessarily want to do it, I think our memory ordering rules would be
*much* better for strongly stating that it has to work, than being
timid and trying to make the rules weak.

Memory ordering is confusing enough as it is. We should not make
people worry more than they already have to. Strong rules are good.

                    Linus