The memory barrier dma_mb() is introduced by commit a76a37777f2c
("iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer"),
which is used to ensure that prior (both reads and writes) accesses
to memory by a CPU are ordered w.r.t. a subsequent MMIO write, this
is only defined on arm64, but it is a generic memory barrier, let's
add dma_mb() into documentation and include/asm-generic/barrier.h.
Signed-off-by: Kefeng Wang <[email protected]>
---
Documentation/memory-barriers.txt | 11 ++++++-----
include/asm-generic/barrier.h | 8 ++++++++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index b12df9137e1c..07a8b8e1b12a 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -1894,6 +1894,7 @@ There are some more advanced barrier functions:
(*) dma_wmb();
(*) dma_rmb();
+ (*) dma_mb();
These are for use with consistent memory to guarantee the ordering
of writes or reads of shared memory accessible to both the CPU and a
@@ -1925,11 +1926,11 @@ There are some more advanced barrier functions:
The dma_rmb() allows us guarantee the device has released ownership
before we read the data from the descriptor, and the dma_wmb() allows
us to guarantee the data is written to the descriptor before the device
- can see it now has ownership. 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. The cheaper
- writel_relaxed() does not provide this guarantee and must not be used
- here.
+ can see it now has ownership. The dma_mb() implies both a dma_rmb() and
+ a dma_wmb(). 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. The cheaper writel_relaxed() does not provide
+ this guarantee and must not be used here.
See the subsection "Kernel I/O barrier effects" for more information on
relaxed I/O accessors and the Documentation/core-api/dma-api.rst file for
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index fd7e8fbaeef1..961f4d88f9ef 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -38,6 +38,10 @@
#define wmb() do { kcsan_wmb(); __wmb(); } while (0)
#endif
+#ifdef __dma_mb
+#define dma_mb() do { kcsan_mb(); __dma_mb(); } while (0)
+#endif
+
#ifdef __dma_rmb
#define dma_rmb() do { kcsan_rmb(); __dma_rmb(); } while (0)
#endif
@@ -65,6 +69,10 @@
#define wmb() mb()
#endif
+#ifndef dma_mb
+#define dma_mb() mb()
+#endif
+
#ifndef dma_rmb
#define dma_rmb() rmb()
#endif
--
2.35.3
On Mon, 23 May 2022 at 03:50, Kefeng Wang <[email protected]> wrote:
>
> The memory barrier dma_mb() is introduced by commit a76a37777f2c
> ("iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer"),
> which is used to ensure that prior (both reads and writes) accesses
> to memory by a CPU are ordered w.r.t. a subsequent MMIO write, this
> is only defined on arm64, but it is a generic memory barrier, let's
> add dma_mb() into documentation and include/asm-generic/barrier.h.
>
> Signed-off-by: Kefeng Wang <[email protected]>
> ---
> Documentation/memory-barriers.txt | 11 ++++++-----
> include/asm-generic/barrier.h | 8 ++++++++
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index b12df9137e1c..07a8b8e1b12a 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -1894,6 +1894,7 @@ There are some more advanced barrier functions:
>
> (*) dma_wmb();
> (*) dma_rmb();
> + (*) dma_mb();
>
> These are for use with consistent memory to guarantee the ordering
> of writes or reads of shared memory accessible to both the CPU and a
> @@ -1925,11 +1926,11 @@ There are some more advanced barrier functions:
> The dma_rmb() allows us guarantee the device has released ownership
> before we read the data from the descriptor, and the dma_wmb() allows
> us to guarantee the data is written to the descriptor before the device
> - can see it now has ownership. 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. The cheaper
> - writel_relaxed() does not provide this guarantee and must not be used
> - here.
> + can see it now has ownership. The dma_mb() implies both a dma_rmb() and
> + a dma_wmb(). 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. The cheaper writel_relaxed() does not provide
> + this guarantee and must not be used here.
It seems you've changed that spacing. This document uses 2 spaces
after a sentence-ending '.'. (My original suggestion included the 2
spaces after dots.)
Otherwise it all looks fine to me.
Thanks,
-- Marco
On Mon, May 23, 2022 at 4:00 AM Kefeng Wang <[email protected]> wrote:
>
> The memory barrier dma_mb() is introduced by commit a76a37777f2c
> ("iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer"),
> which is used to ensure that prior (both reads and writes) accesses
> to memory by a CPU are ordered w.r.t. a subsequent MMIO write, this
> is only defined on arm64, but it is a generic memory barrier, let's
> add dma_mb() into documentation and include/asm-generic/barrier.h.
>
> Signed-off-by: Kefeng Wang <[email protected]>
> ---
I assume you plan this to get merged through the arm64 tree.
Reviewed-by: Arnd Bergmann <[email protected]> # for asm-generic
On 2022/5/23 16:22, Marco Elver wrote:
> On Mon, 23 May 2022 at 03:50, Kefeng Wang <[email protected]> wrote:
>> The memory barrier dma_mb() is introduced by commit a76a37777f2c
>> ("iommu/arm-smmu-v3: Ensure queue is read after updating prod pointer"),
>> which is used to ensure that prior (both reads and writes) accesses
>> to memory by a CPU are ordered w.r.t. a subsequent MMIO write, this
>> is only defined on arm64, but it is a generic memory barrier, let's
>> add dma_mb() into documentation and include/asm-generic/barrier.h.
>>
>> Signed-off-by: Kefeng Wang <[email protected]>
>> ---
>> Documentation/memory-barriers.txt | 11 ++++++-----
>> include/asm-generic/barrier.h | 8 ++++++++
>> 2 files changed, 14 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
>> index b12df9137e1c..07a8b8e1b12a 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1894,6 +1894,7 @@ There are some more advanced barrier functions:
>>
>> (*) dma_wmb();
>> (*) dma_rmb();
>> + (*) dma_mb();
>>
>> These are for use with consistent memory to guarantee the ordering
>> of writes or reads of shared memory accessible to both the CPU and a
>> @@ -1925,11 +1926,11 @@ There are some more advanced barrier functions:
>> The dma_rmb() allows us guarantee the device has released ownership
>> before we read the data from the descriptor, and the dma_wmb() allows
>> us to guarantee the data is written to the descriptor before the device
>> - can see it now has ownership. 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. The cheaper
>> - writel_relaxed() does not provide this guarantee and must not be used
>> - here.
>> + can see it now has ownership. The dma_mb() implies both a dma_rmb() and
>> + a dma_wmb(). 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. The cheaper writel_relaxed() does not provide
>> + this guarantee and must not be used here.
> It seems you've changed that spacing. This document uses 2 spaces
> after a sentence-ending '.'. (My original suggestion included the 2
> spaces after dots.)
I don't know the rules, it seems that some uses 1 spaces, others are 2
spaces, but most
uses 2 spaces, will update.
> Otherwise it all looks fine to me.
>
> Thanks,
> -- Marco
> .