Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a9c64b36-9770-1198-7958-3d66b98737c1@gmail.com>
Date:   Tue, 18 Oct 2022 18:23:39 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH v4] locking/memory-barriers.txt: Improve documentation for
 writel() example
To:     Arnd Bergmann <arnd@arndb.de>, Parav Pandit <parav@nvidia.com>
Cc:     Bagas Sanjaya <bagasdotme@gmail.com>,
        Alan Stern <stern@rowland.harvard.edu>, parri.andrea@gmail.com,
        Will Deacon <will@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>, boqun.feng@gmail.com,
        Nicholas Piggin <npiggin@gmail.com>, dhowells@redhat.com,
        j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
        "Paul E. McKenney" <paulmck@kernel.org>, dlustig@nvidia.com,
        Joel Fernandes <joel@joelfernandes.org>,
        Jonathan Corbet <corbet@lwn.net>, linux-kernel@vger.kernel.org,
        Linux-Arch <linux-arch@vger.kernel.org>,
        linux-doc@vger.kernel.org, Akira Yokosawa <akiyks@gmail.com>
References: <20221010101331.29942-1-parav@nvidia.com>
 <d5faaf6f-7de5-49b0-92d6-9989ffbdbf2e@app.fastmail.com>
 <59d99be6-f79e-45bd-203c-17972255cc39@gmail.com>
 <12f51033-1461-43f9-8d8d-cd726fbb4758@app.fastmail.com>
 <a91e8216-7767-9126-e1d2-c67846cf32fc@gmail.com>
 <b88e4bd2-5c2e-430a-99f9-18cd43463fd6@app.fastmail.com>
Content-Language: en-US
From:   Akira Yokosawa <akiyks@gmail.com>
In-Reply-To: <b88e4bd2-5c2e-430a-99f9-18cd43463fd6@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 18 Oct 2022 09:49:34 +0200, Arnd Bergmann wrote:
> On Tue, Oct 18, 2022, at 9:40 AM, Akira Yokosawa wrote:
>> On Tue, 18 Oct 2022 08:44:09 +0200, Arnd Bergmann wrote:
>>>
>>> Anything weaker than a full "wmb()" probably makes the driver calling
>>> the writel() non-portable, so that is both vague and incorrect.
>>
>> Do you mean there is a writel() implementation somewhere in the kernel
>> which doesn't guarantee an implicit wmb() before MMIO write?
> 
> There are lots of those, but that's not what I meant. E.g. on x86,
> writel() does not imply a full wmb() but still guarantees serialization
> between DMA and the register access.
> 
>> Or do you mean my version is confusing because it can imply a weaker
>> write barrier is sufficient before writel_relaxed()?
> 
> That's what I meant, yes. On a lot of architectures, it is sufficient
> to have something weaker than wmb() before writel_relaxed(), especially
> on anything that defines writel_relaxed() to be the same as writel(),
> any barrier would technically work. On arm32, using __iowmb() would be
> sufficient, and this can be less than a full wmb() but again it's
> obviously not portable. These details should not be needed in the
> documentation.
Thanks for the clarification.

I think I was confused by the current wording.
I might be wrong, but I guess Parav's motivation of this change was
to prevent this kind of confusion from the first place.

Parav, may I suggest a reworked changelog? :

    The cited commit describes that when using writel(), explcit wmb()
    is not needed. However, wmb() can be an expensive barrier depending
    on platforms. Arch-specific writel() can use a platform-specific
    weaker barrier needed for the guarantee mentioned in section "KERNEL
    I/O BARRIER EFFECTS".

    Current wording of:
        Note that, when using writel(), a prior wmb() is not needed
        to guarantee that the cache coherent memory writes have completed
        before writing to the MMIO region.

    is confusing because it can be interpreted that writel() always has
    a barrier equivalent to the heavy-weight wmb(), which is not the case.

    Hence stop mentioning wmb() and just call "a prior barrier" in the
    notice.

    commit 5846581e3563 ("locking/memory-barriers.txt: Fix broken DMA vs. MMIO ordering example")

Am I still missing something?

        Thanks, Akira

> 
>       Arnd