* [PATCH v2 0/2] arm64: Fix kcsan test_barrier fail and panic @ 2022-05-20 3:15 ` Kefeng Wang 0 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang Fix selftest and kcsan_test() module fail when KCSAN_STRICT and KCSAN_WEAK_MEMORY enabled on ARM64. v2: - Add documents about dma_mb(), suggested Mike and Will. - drop Fixes tag and update changlog, suggested Mike. Kefeng Wang (2): Documentation/barriers: Add memory barrier dma_mb() arm64: kcsan: Support detecting more missing memory barriers Documentation/memory-barriers.txt | 5 ++++- arch/arm64/include/asm/barrier.h | 12 ++++++------ include/asm-generic/barrier.h | 4 ++++ 3 files changed, 14 insertions(+), 7 deletions(-) -- 2.35.3 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 0/2] arm64: Fix kcsan test_barrier fail and panic @ 2022-05-20 3:15 ` Kefeng Wang 0 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang Fix selftest and kcsan_test() module fail when KCSAN_STRICT and KCSAN_WEAK_MEMORY enabled on ARM64. v2: - Add documents about dma_mb(), suggested Mike and Will. - drop Fixes tag and update changlog, suggested Mike. Kefeng Wang (2): Documentation/barriers: Add memory barrier dma_mb() arm64: kcsan: Support detecting more missing memory barriers Documentation/memory-barriers.txt | 5 ++++- arch/arm64/include/asm/barrier.h | 12 ++++++------ include/asm-generic/barrier.h | 4 ++++ 3 files changed, 14 insertions(+), 7 deletions(-) -- 2.35.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() 2022-05-20 3:15 ` Kefeng Wang @ 2022-05-20 3:15 ` Kefeng Wang -1 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang 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. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- Documentation/memory-barriers.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b12df9137e1c..1eabcc0e4eca 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1894,10 +1894,13 @@ 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 - DMA capable device. + DMA capable device, in the case of ensure the prior (both reads and + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent + MMIO write, dma_mb(). For example, consider a device driver that shares memory with a device and uses a descriptor status value to indicate if the descriptor belongs -- 2.35.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() @ 2022-05-20 3:15 ` Kefeng Wang 0 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang 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. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- Documentation/memory-barriers.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b12df9137e1c..1eabcc0e4eca 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1894,10 +1894,13 @@ 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 - DMA capable device. + DMA capable device, in the case of ensure the prior (both reads and + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent + MMIO write, dma_mb(). For example, consider a device driver that shares memory with a device and uses a descriptor status value to indicate if the descriptor belongs -- 2.35.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() 2022-05-20 3:15 ` Kefeng Wang @ 2022-05-20 10:08 ` Marco Elver -1 siblings, 0 replies; 12+ messages in thread From: Marco Elver @ 2022-05-20 10:08 UTC (permalink / raw) To: Kefeng Wang Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang 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. > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > Documentation/memory-barriers.txt | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index b12df9137e1c..1eabcc0e4eca 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -1894,10 +1894,13 @@ 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 > - DMA capable device. > + DMA capable device, in the case of ensure the prior (both reads and > + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent > + MMIO write, dma_mb(). > I think this is out of place; this explanation here is not yet elaborating on either. Elaboration on dma_mb() should go where dma_rmb() and dma_wmb() are explained. Something like this: ------ >8 ------ diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b12df9137e1c..fb322b6cce70 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 ------ >8 ------ Also, now that you're making dma_mb() part of the official API, it might need a generic definition in include/asm-generic/barrier.h, because as-is it's only available in arm64 builds. Thoughts? Thanks, -- Marco ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() @ 2022-05-20 10:08 ` Marco Elver 0 siblings, 0 replies; 12+ messages in thread From: Marco Elver @ 2022-05-20 10:08 UTC (permalink / raw) To: Kefeng Wang Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang 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. > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > Documentation/memory-barriers.txt | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index b12df9137e1c..1eabcc0e4eca 100644 > --- a/Documentation/memory-barriers.txt > +++ b/Documentation/memory-barriers.txt > @@ -1894,10 +1894,13 @@ 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 > - DMA capable device. > + DMA capable device, in the case of ensure the prior (both reads and > + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent > + MMIO write, dma_mb(). > I think this is out of place; this explanation here is not yet elaborating on either. Elaboration on dma_mb() should go where dma_rmb() and dma_wmb() are explained. Something like this: ------ >8 ------ diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index b12df9137e1c..fb322b6cce70 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 ------ >8 ------ Also, now that you're making dma_mb() part of the official API, it might need a generic definition in include/asm-generic/barrier.h, because as-is it's only available in arm64 builds. Thoughts? Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() 2022-05-20 10:08 ` Marco Elver @ 2022-05-20 11:14 ` Kefeng Wang -1 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 11:14 UTC (permalink / raw) To: Marco Elver Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On 2022/5/20 18:08, Marco Elver wrote: > On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang 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. >> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> --- >> Documentation/memory-barriers.txt | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt >> index b12df9137e1c..1eabcc0e4eca 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -1894,10 +1894,13 @@ 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 >> - DMA capable device. >> + DMA capable device, in the case of ensure the prior (both reads and >> + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent >> + MMIO write, dma_mb(). >> > I think this is out of place; this explanation here is not yet > elaborating on either. Elaboration on dma_mb() should go where > dma_rmb() and dma_wmb() are explained. > > Something like this: > > ------ >8 ------ > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index b12df9137e1c..fb322b6cce70 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 > > ------ >8 ------ Thanks， will use above explanation. > Also, now that you're making dma_mb() part of the official API, it might > need a generic definition in include/asm-generic/barrier.h, because > as-is it's only available in arm64 builds. Ok, it's good to add the dma_mb() and __dma_mb definition with a separate patch into include/asm-generic/barrier.h. > > Thoughts? > > Thanks, > -- Marco > . ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() @ 2022-05-20 11:14 ` Kefeng Wang 0 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 11:14 UTC (permalink / raw) To: Marco Elver Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On 2022/5/20 18:08, Marco Elver wrote: > On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang 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. >> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> >> --- >> Documentation/memory-barriers.txt | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt >> index b12df9137e1c..1eabcc0e4eca 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -1894,10 +1894,13 @@ 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 >> - DMA capable device. >> + DMA capable device, in the case of ensure the prior (both reads and >> + writes) accesses to memory by a CPU are ordered w.r.t. a subsequent >> + MMIO write, dma_mb(). >> > I think this is out of place; this explanation here is not yet > elaborating on either. Elaboration on dma_mb() should go where > dma_rmb() and dma_wmb() are explained. > > Something like this: > > ------ >8 ------ > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > index b12df9137e1c..fb322b6cce70 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 > > ------ >8 ------ Thanks， will use above explanation. > Also, now that you're making dma_mb() part of the official API, it might > need a generic definition in include/asm-generic/barrier.h, because > as-is it's only available in arm64 builds. Ok, it's good to add the dma_mb() and __dma_mb definition with a separate patch into include/asm-generic/barrier.h. > > Thoughts? > > Thanks, > -- Marco > . _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] arm64: kcsan: Support detecting more missing memory barriers 2022-05-20 3:15 ` Kefeng Wang @ 2022-05-20 3:15 ` Kefeng Wang -1 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang As "kcsan: Support detecting a subset of missing memory barriers"[1] introduced KCSAN_STRICT/KCSAN_WEAK_MEMORY which make kcsan detects more missing memory barrier, but arm64 don't have KCSAN instrumentation for barriers, so the new selftest test_barrier() and test cases for memory barrier instrumentation in kcsan_test module will fail, even panic on selftest. Let's prefix all barriers with __ on arm64, as asm-generic/barriers.h defined the final instrumented version of these barriers, which will fix the above issues. Note, barrier instrumentation that can be disabled via __no_kcsan with appropriate compiler-support (and not just with objtool help), see commit bd3d5bd1a0ad ("kcsan: Support WEAK_MEMORY with Clang where no objtool support exists"), it adds disable_sanitizer_instrumentation to __no_kcsan attribute which will remove all sanitizer instrumentation fully (with Clang 14.0). Meanwhile, GCC does the same thing with no_sanitize. [1] https://lore.kernel.org/linux-mm/20211130114433.2580590-1-elver@google.com/ Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- arch/arm64/include/asm/barrier.h | 12 ++++++------ include/asm-generic/barrier.h | 4 ++++ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h index 9f3e2c3d2ca0..2cfc4245d2e2 100644 --- a/arch/arm64/include/asm/barrier.h +++ b/arch/arm64/include/asm/barrier.h @@ -50,13 +50,13 @@ #define pmr_sync() do {} while (0) #endif -#define mb() dsb(sy) -#define rmb() dsb(ld) -#define wmb() dsb(st) +#define __mb() dsb(sy) +#define __rmb() dsb(ld) +#define __wmb() dsb(st) -#define dma_mb() dmb(osh) -#define dma_rmb() dmb(oshld) -#define dma_wmb() dmb(oshst) +#define __dma_mb() dmb(osh) +#define __dma_rmb() dmb(oshld) +#define __dma_wmb() dmb(oshst) #define io_stop_wc() dgh() diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index fd7e8fbaeef1..18863c50e9ce 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 -- 2.35.3 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] arm64: kcsan: Support detecting more missing memory barriers @ 2022-05-20 3:15 ` Kefeng Wang 0 siblings, 0 replies; 12+ messages in thread From: Kefeng Wang @ 2022-05-20 3:15 UTC (permalink / raw) To: elver, catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet Cc: linux-doc, Kefeng Wang As "kcsan: Support detecting a subset of missing memory barriers"[1] introduced KCSAN_STRICT/KCSAN_WEAK_MEMORY which make kcsan detects more missing memory barrier, but arm64 don't have KCSAN instrumentation for barriers, so the new selftest test_barrier() and test cases for memory barrier instrumentation in kcsan_test module will fail, even panic on selftest. Let's prefix all barriers with __ on arm64, as asm-generic/barriers.h defined the final instrumented version of these barriers, which will fix the above issues. Note, barrier instrumentation that can be disabled via __no_kcsan with appropriate compiler-support (and not just with objtool help), see commit bd3d5bd1a0ad ("kcsan: Support WEAK_MEMORY with Clang where no objtool support exists"), it adds disable_sanitizer_instrumentation to __no_kcsan attribute which will remove all sanitizer instrumentation fully (with Clang 14.0). Meanwhile, GCC does the same thing with no_sanitize. [1] https://lore.kernel.org/linux-mm/20211130114433.2580590-1-elver@google.com/ Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- arch/arm64/include/asm/barrier.h | 12 ++++++------ include/asm-generic/barrier.h | 4 ++++ 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h index 9f3e2c3d2ca0..2cfc4245d2e2 100644 --- a/arch/arm64/include/asm/barrier.h +++ b/arch/arm64/include/asm/barrier.h @@ -50,13 +50,13 @@ #define pmr_sync() do {} while (0) #endif -#define mb() dsb(sy) -#define rmb() dsb(ld) -#define wmb() dsb(st) +#define __mb() dsb(sy) +#define __rmb() dsb(ld) +#define __wmb() dsb(st) -#define dma_mb() dmb(osh) -#define dma_rmb() dmb(oshld) -#define dma_wmb() dmb(oshst) +#define __dma_mb() dmb(osh) +#define __dma_rmb() dmb(oshld) +#define __dma_wmb() dmb(oshst) #define io_stop_wc() dgh() diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h index fd7e8fbaeef1..18863c50e9ce 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 -- 2.35.3 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] arm64: kcsan: Support detecting more missing memory barriers 2022-05-20 3:15 ` Kefeng Wang @ 2022-05-20 10:14 ` Marco Elver -1 siblings, 0 replies; 12+ messages in thread From: Marco Elver @ 2022-05-20 10:14 UTC (permalink / raw) To: Kefeng Wang Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang wrote: > As "kcsan: Support detecting a subset of missing memory barriers"[1] > introduced KCSAN_STRICT/KCSAN_WEAK_MEMORY which make kcsan detects > more missing memory barrier, but arm64 don't have KCSAN instrumentation > for barriers, so the new selftest test_barrier() and test cases for > memory barrier instrumentation in kcsan_test module will fail, even > panic on selftest. > > Let's prefix all barriers with __ on arm64, as asm-generic/barriers.h > defined the final instrumented version of these barriers, which will > fix the above issues. > > Note, barrier instrumentation that can be disabled via __no_kcsan with > appropriate compiler-support (and not just with objtool help), see > commit bd3d5bd1a0ad ("kcsan: Support WEAK_MEMORY with Clang where no > objtool support exists"), it adds disable_sanitizer_instrumentation to > __no_kcsan attribute which will remove all sanitizer instrumentation fully > (with Clang 14.0). Meanwhile, GCC does the same thing with no_sanitize. > > [1] https://lore.kernel.org/linux-mm/20211130114433.2580590-1-elver@google.com/ > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > arch/arm64/include/asm/barrier.h | 12 ++++++------ > include/asm-generic/barrier.h | 4 ++++ > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h > index 9f3e2c3d2ca0..2cfc4245d2e2 100644 > --- a/arch/arm64/include/asm/barrier.h > +++ b/arch/arm64/include/asm/barrier.h > @@ -50,13 +50,13 @@ > #define pmr_sync() do {} while (0) > #endif > > -#define mb() dsb(sy) > -#define rmb() dsb(ld) > -#define wmb() dsb(st) > +#define __mb() dsb(sy) > +#define __rmb() dsb(ld) > +#define __wmb() dsb(st) > > -#define dma_mb() dmb(osh) > -#define dma_rmb() dmb(oshld) > -#define dma_wmb() dmb(oshst) > +#define __dma_mb() dmb(osh) > +#define __dma_rmb() dmb(oshld) > +#define __dma_wmb() dmb(oshst) > > #define io_stop_wc() dgh() > > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > index fd7e8fbaeef1..18863c50e9ce 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 The asm-generic changes might want to go into a separate patch, along with the generic definition of dma_mb() if there's no __dma_mb, as mentioned in the other email. Thanks, -- Marco ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] arm64: kcsan: Support detecting more missing memory barriers @ 2022-05-20 10:14 ` Marco Elver 0 siblings, 0 replies; 12+ messages in thread From: Marco Elver @ 2022-05-20 10:14 UTC (permalink / raw) To: Kefeng Wang Cc: catalin.marinas, will, linux-arm-kernel, linux-kernel, mark.rutland, Jonathan Corbet, linux-doc, paulmck, Peter Zijlstra On Fri, May 20, 2022 at 11:15AM +0800, Kefeng Wang wrote: > As "kcsan: Support detecting a subset of missing memory barriers"[1] > introduced KCSAN_STRICT/KCSAN_WEAK_MEMORY which make kcsan detects > more missing memory barrier, but arm64 don't have KCSAN instrumentation > for barriers, so the new selftest test_barrier() and test cases for > memory barrier instrumentation in kcsan_test module will fail, even > panic on selftest. > > Let's prefix all barriers with __ on arm64, as asm-generic/barriers.h > defined the final instrumented version of these barriers, which will > fix the above issues. > > Note, barrier instrumentation that can be disabled via __no_kcsan with > appropriate compiler-support (and not just with objtool help), see > commit bd3d5bd1a0ad ("kcsan: Support WEAK_MEMORY with Clang where no > objtool support exists"), it adds disable_sanitizer_instrumentation to > __no_kcsan attribute which will remove all sanitizer instrumentation fully > (with Clang 14.0). Meanwhile, GCC does the same thing with no_sanitize. > > [1] https://lore.kernel.org/linux-mm/20211130114433.2580590-1-elver@google.com/ > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > arch/arm64/include/asm/barrier.h | 12 ++++++------ > include/asm-generic/barrier.h | 4 ++++ > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h > index 9f3e2c3d2ca0..2cfc4245d2e2 100644 > --- a/arch/arm64/include/asm/barrier.h > +++ b/arch/arm64/include/asm/barrier.h > @@ -50,13 +50,13 @@ > #define pmr_sync() do {} while (0) > #endif > > -#define mb() dsb(sy) > -#define rmb() dsb(ld) > -#define wmb() dsb(st) > +#define __mb() dsb(sy) > +#define __rmb() dsb(ld) > +#define __wmb() dsb(st) > > -#define dma_mb() dmb(osh) > -#define dma_rmb() dmb(oshld) > -#define dma_wmb() dmb(oshst) > +#define __dma_mb() dmb(osh) > +#define __dma_rmb() dmb(oshld) > +#define __dma_wmb() dmb(oshst) > > #define io_stop_wc() dgh() > > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > index fd7e8fbaeef1..18863c50e9ce 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 The asm-generic changes might want to go into a separate patch, along with the generic definition of dma_mb() if there's no __dma_mb, as mentioned in the other email. Thanks, -- Marco _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-05-20 11:16 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-05-20 3:15 [PATCH v2 0/2] arm64: Fix kcsan test_barrier fail and panic Kefeng Wang 2022-05-20 3:15 ` Kefeng Wang 2022-05-20 3:15 ` [PATCH v2 1/2] Documentation/barriers: Add memory barrier dma_mb() Kefeng Wang 2022-05-20 3:15 ` Kefeng Wang 2022-05-20 10:08 ` Marco Elver 2022-05-20 10:08 ` Marco Elver 2022-05-20 11:14 ` Kefeng Wang 2022-05-20 11:14 ` Kefeng Wang 2022-05-20 3:15 ` [PATCH v2 2/2] arm64: kcsan: Support detecting more missing memory barriers Kefeng Wang 2022-05-20 3:15 ` Kefeng Wang 2022-05-20 10:14 ` Marco Elver 2022-05-20 10:14 ` Marco Elver
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.