Re: [PATCH V6 4/5] iommu/dma-iommu: Use the dev->coherent_dma_mask

2020-07-10 Thread Tom Murphy
>Btw, what is the current state of converting intel-iommu to the dma-iommu

These changes expose a bug in the i915 intel driver which hasn't been
fixed yet. I don't think anyone is actively working on it but I plan
on merging as many patches as I can so it's easier to do the
intel-iommu -> dma-iommu conversion once the bug is fixed.

You can read more about it here:
https://patchwork.kernel.org/cover/11306999/

On Fri, 10 Jul 2020 at 08:59, Christoph Hellwig  wrote:
>
> Btw, what is the current state of converting intel-iommu to the dma-iommu
> code?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] xen: introduce xen_vring_use_dma

2020-07-10 Thread Stefano Stabellini
Sorry for the late reply -- a couple of conferences kept me busy.


On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stefano Stabellini wrote:
> > Would you be in favor of a more flexible check along the lines of the
> > one proposed in the patch that started this thread:
> > 
> > if (xen_vring_use_dma())
> > return true;
> > 
> > 
> > xen_vring_use_dma would be implemented so that it returns true when
> > xen_swiotlb is required and false otherwise.
> 
> Just to stress - with a patch like this virtio can *still* use DMA API
> if PLATFORM_ACCESS is set. So if DMA API is broken on some platforms
> as you seem to be saying, you guys should fix it before doing something
> like this..

Yes, DMA API is broken with some interfaces (specifically: rpmesg and
trusty), but for them PLATFORM_ACCESS is never set. That is why the
errors weren't reported before. Xen special case aside, there is no
problem under normal circumstances.


If you are OK with this patch (after a little bit of clean-up), Peng,
are you OK with sending an update or do you want me to?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v3 06/19] asm/rwonce: Don't pull into 'asm-generic/rwonce.h'

2020-07-10 Thread Will Deacon
On Fri, Jul 10, 2020 at 10:06:12AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 10, 2020 at 9:52 AM Will Deacon  wrote:
> > diff --git a/include/linux/nospec.h b/include/linux/nospec.h
> > index 0c5ef54fd416..c1e79f72cd89 100644
> > --- a/include/linux/nospec.h
> > +++ b/include/linux/nospec.h
> > @@ -5,6 +5,8 @@
> >
> >  #ifndef _LINUX_NOSPEC_H
> >  #define _LINUX_NOSPEC_H
> > +
> > +#include 
> 
> The other hunks LGTM, but this one is a little more curious to me. Can
> you walk me through this addition?

Sure. Without it, the build breaks on riscv because it includes this header
without first including , and this header relies on
OPTIMIZER_HIDE_VAR() being to defined as it is used in static inline
functions.

Perhaps I should squash this hunk into "compiler.h: Split {READ,WRITE}_ONCE
definitions out into rwonce.h" instead, as that is where I remove the
include of  from 'asm-generic/barrier.h'. I'll check
the bisection on riscv...

Will
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v3 06/19] asm/rwonce: Don't pull into 'asm-generic/rwonce.h'

2020-07-10 Thread Nick Desaulniers via Virtualization
On Fri, Jul 10, 2020 at 9:52 AM Will Deacon  wrote:
>
> Now that 'smp_read_barrier_depends()' has gone the way of the Norwegian
> Blue, drop the inclusion of  in 'asm-generic/rwonce.h'.
>
> This requires fixups to some architecture vdso headers which were
> previously relying on 'asm/barrier.h' coming in via 'linux/compiler.h'.
>
> Signed-off-by: Will Deacon 
> ---
>  arch/arm/include/asm/vdso/gettimeofday.h  | 1 +
>  arch/arm64/include/asm/vdso/compat_gettimeofday.h | 1 +
>  arch/arm64/include/asm/vdso/gettimeofday.h| 1 +
>  arch/riscv/include/asm/vdso/gettimeofday.h| 1 +
>  include/asm-generic/rwonce.h  | 2 --
>  include/linux/nospec.h| 2 ++
>  6 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/vdso/gettimeofday.h 
> b/arch/arm/include/asm/vdso/gettimeofday.h
> index 36dc18553ed8..1b207cf07697 100644
> --- a/arch/arm/include/asm/vdso/gettimeofday.h
> +++ b/arch/arm/include/asm/vdso/gettimeofday.h
> @@ -7,6 +7,7 @@
>
>  #ifndef __ASSEMBLY__
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h 
> b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
> index b6907ae78e53..bcf764a4 100644
> --- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
> +++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
> @@ -7,6 +7,7 @@
>
>  #ifndef __ASSEMBLY__
>
> +#include 
>  #include 
>  #include 
>
> diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h 
> b/arch/arm64/include/asm/vdso/gettimeofday.h
> index afba6ba332f8..127fa63893e2 100644
> --- a/arch/arm64/include/asm/vdso/gettimeofday.h
> +++ b/arch/arm64/include/asm/vdso/gettimeofday.h
> @@ -7,6 +7,7 @@
>
>  #ifndef __ASSEMBLY__
>
> +#include 
>  #include 
>
>  #define VDSO_HAS_CLOCK_GETRES  1
> diff --git a/arch/riscv/include/asm/vdso/gettimeofday.h 
> b/arch/riscv/include/asm/vdso/gettimeofday.h
> index c8e818688ec1..3099362d9f26 100644
> --- a/arch/riscv/include/asm/vdso/gettimeofday.h
> +++ b/arch/riscv/include/asm/vdso/gettimeofday.h
> @@ -4,6 +4,7 @@
>
>  #ifndef __ASSEMBLY__
>
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
> index cc810f1f18ca..cd0302746fb4 100644
> --- a/include/asm-generic/rwonce.h
> +++ b/include/asm-generic/rwonce.h
> @@ -26,8 +26,6 @@
>  #include 
>  #include 
>
> -#include 
> -
>  /*
>   * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
>   * atomicity. Note that this may result in tears!
> diff --git a/include/linux/nospec.h b/include/linux/nospec.h
> index 0c5ef54fd416..c1e79f72cd89 100644
> --- a/include/linux/nospec.h
> +++ b/include/linux/nospec.h
> @@ -5,6 +5,8 @@
>
>  #ifndef _LINUX_NOSPEC_H
>  #define _LINUX_NOSPEC_H
> +
> +#include 

The other hunks LGTM, but this one is a little more curious to me. Can
you walk me through this addition?

>  #include 
>
>  struct task_struct;
> --
> 2.27.0.383.g050319c2ae-goog
>


-- 
Thanks,
~Nick Desaulniers
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 17/19] arm64: cpufeatures: Add capability for LDAPR instruction

2020-07-10 Thread Will Deacon
Armv8.3 introduced the LDAPR instruction, which provides weaker memory
ordering semantics than LDARi (RCpc vs RCsc). Generally, we provide an
RCsc implementation when implementing the Linux memory model, but LDAPR
can be used as a useful alternative to dependency ordering, particularly
when the compiler is capable of breaking the dependencies.

Since LDAPR is not available on all CPUs, add a cpufeature to detect it at
runtime and allow the instruction to be used with alternative code
patching.

Signed-off-by: Will Deacon 
---
 arch/arm64/Kconfig   |  3 +++
 arch/arm64/include/asm/cpucaps.h |  3 ++-
 arch/arm64/kernel/cpufeature.c   | 10 ++
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 66dc41fd49f2..e1073210e70b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1409,6 +1409,9 @@ config ARM64_PAN
 The feature is detected at runtime, and will remain as a 'nop'
 instruction if the cpu does not implement the feature.
 
+config AS_HAS_LDAPR
+   def_bool $(as-instr,.arch_extension rcpc)
+
 config ARM64_LSE_ATOMICS
bool
default ARM64_USE_LSE_ATOMICS
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index d7b3bb0cb180..3ff0103d4dfd 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -62,7 +62,8 @@
 #define ARM64_HAS_GENERIC_AUTH 52
 #define ARM64_HAS_32BIT_EL153
 #define ARM64_BTI  54
+#define ARM64_HAS_LDAPR55
 
-#define ARM64_NCAPS55
+#define ARM64_NCAPS56
 
 #endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9fae0efc80c1..498bd9a7f1bc 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2058,6 +2058,16 @@ static const struct arm64_cpu_capabilities 
arm64_features[] = {
.sign = FTR_UNSIGNED,
},
 #endif
+   {
+   .desc = "RCpc load-acquire (LDAPR)",
+   .capability = ARM64_HAS_LDAPR,
+   .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+   .sys_reg = SYS_ID_AA64ISAR1_EL1,
+   .sign = FTR_UNSIGNED,
+   .field_pos = ID_AA64ISAR1_LRCPC_SHIFT,
+   .matches = has_cpuid_feature,
+   .min_field_value = 1,
+   },
{},
 };
 
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 04/19] alpha: Override READ_ONCE() with barriered implementation

2020-07-10 Thread Will Deacon
Rather then relying on the core code to use smp_read_barrier_depends()
as part of the READ_ONCE() definition, instead override __READ_ONCE()
in the Alpha code so that it generates the required mb() and then
implement smp_load_acquire() using the new macro to avoid redundant
back-to-back barriers from the generic implementation.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 arch/alpha/include/asm/barrier.h | 59 +++-
 arch/alpha/include/asm/rwonce.h  | 35 +++
 2 files changed, 40 insertions(+), 54 deletions(-)
 create mode 100644 arch/alpha/include/asm/rwonce.h

diff --git a/arch/alpha/include/asm/barrier.h b/arch/alpha/include/asm/barrier.h
index 92ec486a4f9e..c56bfffc9918 100644
--- a/arch/alpha/include/asm/barrier.h
+++ b/arch/alpha/include/asm/barrier.h
@@ -2,64 +2,15 @@
 #ifndef __BARRIER_H
 #define __BARRIER_H
 
-#include 
-
 #define mb()   __asm__ __volatile__("mb": : :"memory")
 #define rmb()  __asm__ __volatile__("mb": : :"memory")
 #define wmb()  __asm__ __volatile__("wmb": : :"memory")
 
-/**
- * read_barrier_depends - Flush all pending reads that subsequents reads
- * depend on.
- *
- * No data-dependent reads from memory-like regions are ever reordered
- * over this barrier.  All reads preceding this primitive are guaranteed
- * to access memory (but not necessarily other CPUs' caches) before any
- * reads following this primitive that depend on the data return by
- * any of the preceding reads.  This primitive is much lighter weight than
- * rmb() on most CPUs, and is never heavier weight than is
- * rmb().
- *
- * These ordering constraints are respected by both the local CPU
- * and the compiler.
- *
- * Ordering is not guaranteed by anything other than these primitives,
- * not even by data dependencies.  See the documentation for
- * memory_barrier() for examples and URLs to more information.
- *
- * For example, the following code would force ordering (the initial
- * value of "a" is zero, "b" is one, and "p" is "&a"):
- *
- * 
- * CPU 0   CPU 1
- *
- * b = 2;
- * memory_barrier();
- * p = &b; q = p;
- * read_barrier_depends();
- * d = *q;
- * 
- *
- * because the read of "*q" depends on the read of "p" and these
- * two reads are separated by a read_barrier_depends().  However,
- * the following code, with the same initial values for "a" and "b":
- *
- * 
- * CPU 0   CPU 1
- *
- * a = 2;
- * memory_barrier();
- * b = 3;  y = b;
- * read_barrier_depends();
- * x = a;
- * 
- *
- * does not enforce ordering, since there is no data dependency between
- * the read of "a" and the read of "b".  Therefore, on some CPUs, such
- * as Alpha, "y" could be set to 3 and "x" to 0.  Use rmb()
- * in cases like this where there are no data dependencies.
- */
-#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory")
+#define __smp_load_acquire(p)  \
+({ \
+   compiletime_assert_atomic_type(*p); \
+   __READ_ONCE(*p);\
+})
 
 #ifdef CONFIG_SMP
 #define __ASM_SMP_MB   "\tmb\n"
diff --git a/arch/alpha/include/asm/rwonce.h b/arch/alpha/include/asm/rwonce.h
new file mode 100644
index ..35542bcf92b3
--- /dev/null
+++ b/arch/alpha/include/asm/rwonce.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_SMP
+
+#include 
+
+/*
+ * Alpha is apparently daft enough to reorder address-dependent loads
+ * on some CPU implementations. Knock some common sense into it with
+ * a memory barrier in READ_ONCE().
+ *
+ * For the curious, more information about this unusual reordering is
+ * available in chapter 15 of the "perfbook":
+ *
+ *  https://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html
+ *
+ */
+#define __READ_ONCE(x) \
+({ \
+   __unqual_scalar_typeof(x) __x = \
+   (*(volatile typeof(__x) *)(&(x)));  \
+   mb();   \
+   (typeof(x))__x; \
+})
+
+#endif /* CONFIG_SMP */
+
+#include 
+
+#endif /* __ASM_RWONCE_H */
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 16/19] arm64: alternatives: Split up alternative.h

2020-07-10 Thread Will Deacon
asm/alternative.h contains both the macros needed to use alternatives,
as well the type definitions and function prototypes for applying them.

Split the header in two, so that alternatives can be used from core
header files such as linux/compiler.h without the risk of circular
includes

Signed-off-by: Will Deacon 
---
 arch/arm64/include/asm/alternative-macros.h | 276 
 arch/arm64/include/asm/alternative.h| 267 +--
 arch/arm64/include/asm/insn.h   |   3 +-
 3 files changed, 279 insertions(+), 267 deletions(-)
 create mode 100644 arch/arm64/include/asm/alternative-macros.h

diff --git a/arch/arm64/include/asm/alternative-macros.h 
b/arch/arm64/include/asm/alternative-macros.h
new file mode 100644
index ..8f4e4b60e72a
--- /dev/null
+++ b/arch/arm64/include/asm/alternative-macros.h
@@ -0,0 +1,276 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ASM_ALTERNATIVE_MACROS_H
+#define __ASM_ALTERNATIVE_MACROS_H
+
+#include 
+
+#define ARM64_CB_PATCH ARM64_NCAPS
+
+/* A64 instructions are always 32 bits. */
+#defineAARCH64_INSN_SIZE   4
+
+#ifndef __ASSEMBLY__
+
+#include 
+
+#define ALTINSTR_ENTRY(feature)
  \
+   " .word 661b - .\n" /* label   */ \
+   " .word 663f - .\n" /* new instruction */ \
+   " .hword " __stringify(feature) "\n"/* feature bit */ \
+   " .byte 662b-661b\n"/* source len  */ \
+   " .byte 664f-663f\n"/* replacement len */
+
+#define ALTINSTR_ENTRY_CB(feature, cb)   \
+   " .word 661b - .\n" /* label   */ \
+   " .word " __stringify(cb) "- .\n"   /* callback */\
+   " .hword " __stringify(feature) "\n"/* feature bit */ \
+   " .byte 662b-661b\n"/* source len  */ \
+   " .byte 664f-663f\n"/* replacement len */
+
+/*
+ * alternative assembly primitive:
+ *
+ * If any of these .org directive fail, it means that insn1 and insn2
+ * don't have the same length. This used to be written as
+ *
+ * .if ((664b-663b) != (662b-661b))
+ * .error "Alternatives instruction length mismatch"
+ * .endif
+ *
+ * but most assemblers die if insn1 or insn2 have a .inst. This should
+ * be fixed in a binutils release posterior to 2.25.51.0.2 (anything
+ * containing commit 4e4d08cf7399b606 or c1baaddf8861).
+ *
+ * Alternatives with callbacks do not generate replacement instructions.
+ */
+#define __ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg_enabled)\
+   ".if "__stringify(cfg_enabled)" == 1\n" \
+   "661:\n\t"  \
+   oldinstr "\n"   \
+   "662:\n"\
+   ".pushsection .altinstructions,\"a\"\n" \
+   ALTINSTR_ENTRY(feature) \
+   ".popsection\n" \
+   ".subsection 1\n"   \
+   "663:\n\t"  \
+   newinstr "\n"   \
+   "664:\n\t"  \
+   ".previous\n\t" \
+   ".org   . - (664b-663b) + (662b-661b)\n\t"  \
+   ".org   . - (662b-661b) + (664b-663b)\n"\
+   ".endif\n"
+
+#define __ALTERNATIVE_CFG_CB(oldinstr, feature, cfg_enabled, cb)   \
+   ".if "__stringify(cfg_enabled)" == 1\n" \
+   "661:\n\t"  \
+   oldinstr "\n"   \
+   "662:\n"\
+   ".pushsection .altinstructions,\"a\"\n" \
+   ALTINSTR_ENTRY_CB(feature, cb)  \
+   ".popsection\n" \
+   "663:\n\t"  \
+   "664:\n\t"  \
+   ".endif\n"
+
+#define _ALTERNATIVE_CFG(oldinstr, newinstr, feature, cfg, ...)\
+   __ALTERNATIVE_CFG(oldinstr, newinstr, feature, IS_ENABLED(cfg))
+
+#define ALTERNATIVE_CB(oldinstr, cb) \
+   __ALTERNATIVE_CFG_CB(oldinstr, ARM64_CB_PATCH, 1, cb)
+#else
+
+#include 
+
+.macro altinstruction_entry orig_offset alt_offset feature orig_len alt_len
+   .word \orig_offset - .
+   .word

[PATCH v3 18/19] arm64: alternatives: Remove READ_ONCE() usage during patch operation

2020-07-10 Thread Will Deacon
In preparation for patching the internals of READ_ONCE() itself, replace
its usage on the alternatives patching patch with a volatile variable
instead.

Signed-off-by: Will Deacon 
---
 arch/arm64/kernel/alternative.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
index d1757ef1b1e7..87bca8d44084 100644
--- a/arch/arm64/kernel/alternative.c
+++ b/arch/arm64/kernel/alternative.c
@@ -21,7 +21,8 @@
 #define ALT_ORIG_PTR(a)__ALT_PTR(a, orig_offset)
 #define ALT_REPL_PTR(a)__ALT_PTR(a, alt_offset)
 
-static int all_alternatives_applied;
+/* Volatile, as we may be patching the guts of READ_ONCE() */
+static volatile int all_alternatives_applied;
 
 static DECLARE_BITMAP(applied_alternatives, ARM64_NCAPS);
 
@@ -217,7 +218,7 @@ static int __apply_alternatives_multi_stop(void *unused)
 
/* We always have a CPU 0 at this point (__init) */
if (smp_processor_id()) {
-   while (!READ_ONCE(all_alternatives_applied))
+   while (!all_alternatives_applied)
cpu_relax();
isb();
} else {
@@ -229,7 +230,7 @@ static int __apply_alternatives_multi_stop(void *unused)
BUG_ON(all_alternatives_applied);
__apply_alternatives(®ion, false, remaining_capabilities);
/* Barriers provided by the cache flushing */
-   WRITE_ONCE(all_alternatives_applied, 1);
+   all_alternatives_applied = 1;
}
 
return 0;
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 12/19] tools/memory-model: Remove smp_read_barrier_depends() from informal doc

2020-07-10 Thread Will Deacon
smp_read_barrier_depends() has gone the way of mmiowb() and so many
esoteric memory barriers before it. Drop the two mentions of this
deceased barrier from the LKMM informal explanation document.

Acked-by: Alan Stern 
Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 .../Documentation/explanation.txt | 26 +--
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/tools/memory-model/Documentation/explanation.txt 
b/tools/memory-model/Documentation/explanation.txt
index e91a2eb19592..01adf9e0ebac 100644
--- a/tools/memory-model/Documentation/explanation.txt
+++ b/tools/memory-model/Documentation/explanation.txt
@@ -1122,12 +1122,10 @@ maintain at least the appearance of FIFO order.
 In practice, this difficulty is solved by inserting a special fence
 between P1's two loads when the kernel is compiled for the Alpha
 architecture.  In fact, as of version 4.15, the kernel automatically
-adds this fence (called smp_read_barrier_depends() and defined as
-nothing at all on non-Alpha builds) after every READ_ONCE() and atomic
-load.  The effect of the fence is to cause the CPU not to execute any
-po-later instructions until after the local cache has finished
-processing all the stores it has already received.  Thus, if the code
-was changed to:
+adds this fence after every READ_ONCE() and atomic load on Alpha.  The
+effect of the fence is to cause the CPU not to execute any po-later
+instructions until after the local cache has finished processing all
+the stores it has already received.  Thus, if the code was changed to:
 
P1()
{
@@ -1146,14 +1144,14 @@ READ_ONCE() or another synchronization primitive rather 
than accessed
 directly.
 
 The LKMM requires that smp_rmb(), acquire fences, and strong fences
-share this property with smp_read_barrier_depends(): They do not allow
-the CPU to execute any po-later instructions (or po-later loads in the
-case of smp_rmb()) until all outstanding stores have been processed by
-the local cache.  In the case of a strong fence, the CPU first has to
-wait for all of its po-earlier stores to propagate to every other CPU
-in the system; then it has to wait for the local cache to process all
-the stores received as of that time -- not just the stores received
-when the strong fence began.
+share this property: They do not allow the CPU to execute any po-later
+instructions (or po-later loads in the case of smp_rmb()) until all
+outstanding stores have been processed by the local cache.  In the
+case of a strong fence, the CPU first has to wait for all of its
+po-earlier stores to propagate to every other CPU in the system; then
+it has to wait for the local cache to process all the stores received
+as of that time -- not just the stores received when the strong fence
+began.
 
 And of course, none of this matters for any architecture other than
 Alpha.
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 19/19] arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y

2020-07-10 Thread Will Deacon
When building with LTO, there is an increased risk of the compiler
converting an address dependency headed by a READ_ONCE() invocation
into a control dependency and consequently allowing for harmful
reordering by the CPU.

Ensure that such transformations are harmless by overriding the generic
READ_ONCE() definition with one that provides acquire semantics when
building with LTO.

Signed-off-by: Will Deacon 
---
 arch/arm64/include/asm/rwonce.h   | 63 +++
 arch/arm64/kernel/vdso/Makefile   |  2 +-
 arch/arm64/kernel/vdso32/Makefile |  2 +-
 3 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/rwonce.h

diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h
new file mode 100644
index ..d78eb4cb795b
--- /dev/null
+++ b/arch/arm64/include/asm/rwonce.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Google LLC.
+ */
+#ifndef __ASM_RWONCE_H
+#define __ASM_RWONCE_H
+
+#ifdef CONFIG_LTO
+
+#include 
+#include 
+
+#ifndef BUILD_VDSO
+
+#ifdef CONFIG_AS_HAS_LDAPR
+#define __LOAD_RCPC(sfx, regs...)  \
+   ALTERNATIVE(\
+   "ldar"  #sfx "\t" #regs,\
+   ".arch_extension rcpc\n"\
+   "ldapr" #sfx "\t" #regs,\
+   ARM64_HAS_LDAPR)
+#else
+#define __LOAD_RCPC(sfx, regs...)  "ldar" #sfx "\t" #regs
+#endif /* CONFIG_AS_HAS_LDAPR */
+
+#define __READ_ONCE(x) \
+({ \
+   typeof(&(x)) __x = &(x);\
+   int atomic = 1; \
+   union { __unqual_scalar_typeof(*__x) __val; char __c[1]; } __u; \
+   switch (sizeof(x)) {\
+   case 1: \
+   asm volatile(__LOAD_RCPC(b, %w0, %1)\
+   : "=r" (*(__u8 *)__u.__c)   \
+   : "Q" (*__x) : "memory");   \
+   break;  \
+   case 2: \
+   asm volatile(__LOAD_RCPC(h, %w0, %1)\
+   : "=r" (*(__u16 *)__u.__c)  \
+   : "Q" (*__x) : "memory");   \
+   break;  \
+   case 4: \
+   asm volatile(__LOAD_RCPC(, %w0, %1) \
+   : "=r" (*(__u32 *)__u.__c)  \
+   : "Q" (*__x) : "memory");   \
+   break;  \
+   case 8: \
+   asm volatile(__LOAD_RCPC(, %0, %1)  \
+   : "=r" (*(__u64 *)__u.__c)  \
+   : "Q" (*__x) : "memory");   \
+   break;  \
+   default:\
+   atomic = 0; \
+   }   \
+   atomic ? (typeof(*__x))__u.__val : (*(volatile typeof(__x))__x);\
+})
+
+#endif /* !BUILD_VDSO */
+#endif /* CONFIG_LTO */
+
+#include 
+
+#endif /* __ASM_RWONCE_H */
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 45d5cfe46429..60df97f2e7de 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -28,7 +28,7 @@ ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 
--hash-style=sysv  \
 $(btildflags-y) -T
 
 ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
-ccflags-y += -DDISABLE_BRANCH_PROFILING
+ccflags-y += -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 
 CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS) 
$(GCC_PLUGINS_CFLAGS)
 KBUILD_CFLAGS  += $(DISABLE_LTO)
diff --git a/arch/arm64/kernel/vdso32/Makefile 
b/arch/arm64/kernel/vdso32/Makefile
index d88148bef6b0..4fdf3754a058 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -43,7 +43,7 @@ cc32-as-instr = $(call try-run,\
 # As a result we set our own flags here.
 
 # KBUILD_CPPFLAGS and NOSTDINC_FLAGS from top-level Makefile
-VDSO_CPPFLAGS := -D__KERNEL__ -nostdinc -isystem $(shell $(CC_CO

[PATCH v3 13/19] include/linux: Remove smp_read_barrier_depends() from comments

2020-07-10 Thread Will Deacon
smp_read_barrier_depends() doesn't exist any more, so reword the two
comments that mention it to refer to "dependency ordering" instead.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 include/linux/percpu-refcount.h | 2 +-
 include/linux/ptr_ring.h| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/percpu-refcount.h b/include/linux/percpu-refcount.h
index 22d9d183950d..87d8a38bdea1 100644
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -155,7 +155,7 @@ static inline bool __ref_is_percpu(struct percpu_ref *ref,
 * between contaminating the pointer value, meaning that
 * READ_ONCE() is required when fetching it.
 *
-* The smp_read_barrier_depends() implied by READ_ONCE() pairs
+* The dependency ordering from the READ_ONCE() pairs
 * with smp_store_release() in __percpu_ref_switch_to_percpu().
 */
percpu_ptr = READ_ONCE(ref->percpu_count_ptr);
diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h
index 417db0a79a62..808f9d3ee546 100644
--- a/include/linux/ptr_ring.h
+++ b/include/linux/ptr_ring.h
@@ -107,7 +107,7 @@ static inline int __ptr_ring_produce(struct ptr_ring *r, 
void *ptr)
return -ENOSPC;
 
/* Make sure the pointer we are storing points to a valid data. */
-   /* Pairs with smp_read_barrier_depends in __ptr_ring_consume. */
+   /* Pairs with the dependency ordering in __ptr_ring_consume. */
smp_wmb();
 
WRITE_ONCE(r->queue[r->producer++], ptr);
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 14/19] checkpatch: Remove checks relating to [smp_]read_barrier_depends()

2020-07-10 Thread Will Deacon
The [smp_]read_barrier_depends() macros no longer exist, so we don't
need to deal with them in the checkpatch script.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 scripts/checkpatch.pl | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4c820607540b..8032f80c5bc7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -5903,8 +5903,7 @@ sub process {
my $barriers = qr{
mb|
rmb|
-   wmb|
-   read_barrier_depends
+   wmb
}x;
my $barrier_stems = qr{
mb__before_atomic|
@@ -5953,12 +5952,6 @@ sub process {
}
}
 
-# check for smp_read_barrier_depends and read_barrier_depends
-   if (!$file && $line =~ /\b(smp_|)read_barrier_depends\s*\(/) {
-   WARN("READ_BARRIER_DEPENDS",
-"$1read_barrier_depends should only be used in 
READ_ONCE or DEC Alpha code\n" . $herecurr);
-   }
-
 # check of hardware specific defines
if ($line =~ 
m@^.\s*\#\s*if.*\b(__i386__|__powerpc64__|__sun__|__s390x__)\b@ && $realfile !~ 
m@include/asm-@) {
CHK("ARCH_DEFINES",
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 09/19] locking/barriers: Remove definitions for [smp_]read_barrier_depends()

2020-07-10 Thread Will Deacon
There are no remaining users of [smp_]read_barrier_depends(), so
remove it from the generic implementation of 'barrier.h'.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 include/asm-generic/barrier.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 8116744bb82c..fec97dc34de7 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -46,10 +46,6 @@
 #define dma_wmb()  wmb()
 #endif
 
-#ifndef read_barrier_depends
-#define read_barrier_depends() do { } while (0)
-#endif
-
 #ifndef __smp_mb
 #define __smp_mb() mb()
 #endif
@@ -62,10 +58,6 @@
 #define __smp_wmb()wmb()
 #endif
 
-#ifndef __smp_read_barrier_depends
-#define __smp_read_barrier_depends()   read_barrier_depends()
-#endif
-
 #ifdef CONFIG_SMP
 
 #ifndef smp_mb
@@ -80,10 +72,6 @@
 #define smp_wmb()  __smp_wmb()
 #endif
 
-#ifndef smp_read_barrier_depends
-#define smp_read_barrier_depends() __smp_read_barrier_depends()
-#endif
-
 #else  /* !CONFIG_SMP */
 
 #ifndef smp_mb
@@ -98,10 +86,6 @@
 #define smp_wmb()  barrier()
 #endif
 
-#ifndef smp_read_barrier_depends
-#define smp_read_barrier_depends() do { } while (0)
-#endif
-
 #endif /* CONFIG_SMP */
 
 #ifndef __smp_store_mb
@@ -196,7 +180,6 @@ do {
\
 #define virt_mb() __smp_mb()
 #define virt_rmb() __smp_rmb()
 #define virt_wmb() __smp_wmb()
-#define virt_read_barrier_depends() __smp_read_barrier_depends()
 #define virt_store_mb(var, value) __smp_store_mb(var, value)
 #define virt_mb__before_atomic() __smp_mb__before_atomic()
 #define virt_mb__after_atomic()__smp_mb__after_atomic()
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 11/19] Documentation/barriers/kokr: Remove references to [smp_]read_barrier_depends()

2020-07-10 Thread Will Deacon
From: SeongJae Park 

This commit translates commit ("Documentation/barriers: Remove references to
[smp_]read_barrier_depends()") into Korean.

Signed-off-by: SeongJae Park 
Reviewed-by: Yunjae Lee 
Signed-off-by: Will Deacon 
---
 .../translations/ko_KR/memory-barriers.txt| 146 +-
 1 file changed, 3 insertions(+), 143 deletions(-)

diff --git a/Documentation/translations/ko_KR/memory-barriers.txt 
b/Documentation/translations/ko_KR/memory-barriers.txt
index 34d041d68f78..a1f772ef622c 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -577,7 +577,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE 
 데이터 의존성 배리어 (역사적)
 -
 
-리눅스 커널 v4.15 기준으로, smp_read_barrier_depends() 가 READ_ONCE() 에
+리눅스 커널 v4.15 기준으로, smp_mb() 가 DEC Alpha 용 READ_ONCE() 코드에
 추가되었는데, 이는 이 섹션에 주의를 기울여야 하는 사람들은 DEC Alpha 아키텍쳐
 전용 코드를 만드는 사람들과 READ_ONCE() 자체를 만드는 사람들 뿐임을 의미합니다.
 그런 분들을 위해, 그리고 역사에 관심 있는 분들을 위해, 여기 데이터 의존성
@@ -2664,144 +2664,6 @@ CPU 코어는 프로그램의 인과성이 유지된다고만 여겨진다면 
 수도 있습니다.
 
 
-캐시 일관성

-
-하지만 삶은 앞에서 이야기한 것처럼 단순하지 않습니다: 캐시들은 일관적일 것으로
-기대되지만, 그 일관성이 순서에도 적용될 거라는 보장은 없습니다.  한 CPU 에서
-만들어진 변경 사항은 최종적으로는 시스템의 모든 CPU 에게 보여지게 되지만, 다른
-CPU 들에게도 같은 순서로 보이게 될 거라는 보장은 없다는 뜻입니다.
-
-
-두개의 CPU (1 & 2) 가 달려 있고, 각 CPU 에 두개의 데이터 캐시(CPU 1 은 A/B 를,
-CPU 2 는 C/D 를 갖습니다)가 병렬로 연결되어 있는 시스템을 다룬다고 생각해
-봅시다:
-
-   :
-   :  ++
-   :  +-+ ||
-   ++  : +--->| Cache A |<--->||
-   ||  : |+-+ ||
-   |  CPU 1 |<---+||
-   ||  : |+-+ ||
-   ++  : +--->| Cache B |<--->||
-   :  +-+ ||
-   :  | Memory |
-   :  +-+ | System |
-   ++  : +--->| Cache C |<--->||
-   ||  : |+-+ ||
-   |  CPU 2 |<---+||
-   ||  : |+-+ ||
-   ++  : +--->| Cache D |<--->||
-   :  +-+ ||
-   :  ++
-   :
-
-이 시스템이 다음과 같은 특성을 갖는다 생각해 봅시다:
-
- (*) 홀수번 캐시라인은 캐시 A, 캐시 C 또는 메모리에 위치할 수 있음;
-
- (*) 짝수번 캐시라인은 캐시 B, 캐시 D 또는 메모리에 위치할 수 있음;
-
- (*) CPU 코어가 한개의 캐시에 접근하는 동안, 다른 캐시는 - 더티 캐시라인을
- 메모리에 내리거나 추측성 로드를 하거나 하기 위해 - 시스템의 다른 부분에
- 액세스 하기 위해 버스를 사용할 수 있음;
-
- (*) 각 캐시는 시스템의 나머지 부분들과 일관성을 맞추기 위해 해당 캐시에
- 적용되어야 할 오퍼레이션들의 큐를 가짐;
-
- (*) 이 일관성 큐는 캐시에 이미 존재하는 라인에 가해지는 평범한 로드에 의해서는
- 비워지지 않는데, 큐의 오퍼레이션들이 이 로드의 결과에 영향을 끼칠 수 있다
- 할지라도 그러함.
-
-이제, 첫번째 CPU 에서 두개의 쓰기 오퍼레이션을 만드는데, 해당 CPU 의 캐시에
-요청된 순서로 오퍼레이션이 도달됨을 보장하기 위해 두 오퍼레이션 사이에 쓰기
-배리어를 사용하는 상황을 상상해 봅시다:
-
-   CPU 1   CPU 2   COMMENT
-   === === ===
-   u == 0, v == 1 and p == &u, q == &u
-   v = 2;
-   smp_wmb();  v 의 변경이 p 의 변경 전에 보일 것을
-분명히 함
- v 는 이제 캐시 A 에 독점적으로 존재함
-   p = &v;
-p 는 이제 캐시 B 에 독점적으로 존재함
-
-여기서의 쓰기 메모리 배리어는 CPU 1 의 캐시가 올바른 순서로 업데이트 된 것으로
-시스템의 다른 CPU 들이 인지하게 만듭니다.  하지만, 이제 두번째 CPU 가 그 값들을
-읽으려 하는 상황을 생각해 봅시다:
-
-   CPU 1   CPU 2   COMMENT
-   === === ===
-   ...
-   q = p;
-   x = *q;
-
-위의 두개의 읽기 오퍼레이션은 예상된 순서로 일어나지 못할 수 있는데, 두번째 CPU
-의 한 캐시에 다른 캐시 이벤트가 발생해 v 를 담고 있는 캐시라인의 해당 캐시에의
-업데이트가 지연되는 사이, p 를 담고 있는 캐시라인은 두번째 CPU 의 다른 캐시에
-업데이트 되어버렸을 수 있기 때문입니다.
-
-   CPU 1   CPU 2   COMMENT
-   === === ===
-   u == 0, v == 1 and p == &u, q == &u
-   v = 2;
-   smp_wmb();
- 
-   
-   p = &v; q = p;
-   
-
-   
-   x = *q;
-캐시에 업데이트 되기 전의 v 를 읽음
-   
-   
-
-기본적으로, 두개의 캐시라인 모두 CPU 2 에 최종적으로는 업데이트 될 것이지만,
-별도의 개입 없이는, 업데이트의 순서가 CPU 1 에서 만들어진 순서와 동일할
-것이라는 보장이 없습니다.
-
-
-여기에 개입하기 위해선, 데이터 의존성 배리어나 읽기 배리어를 로드 오퍼레이션들
-사이에 넣어야 합니다 (v4.15 부터는 READ_ONCE() 매크로에 의해 무조건적으로
-그렇게 됩니다).  이렇게 함으로써 캐시가 다음 요청을 처리하기 전에 일관성 큐를
-처리하도록 강제하게 됩니다.
-
-   CPU 1   CPU 2   COMMENT
-   === === ===
-   u == 0, v == 1 and p == &u, q == &u
-   v = 2;
-   smp_wmb();
- 
-  

[PATCH v3 15/19] arm64: Reduce the number of header files pulled into vmlinux.lds.S

2020-07-10 Thread Will Deacon
Although vmlinux.lds.S smells like an assembly file and is compiled
with __ASSEMBLY__ defined, it's actually just fed to the preprocessor to
create our linker script. This means that any assembly macros defined
by headers that it includes will result in a helpful link error:

| aarch64-linux-gnu-ld:./arch/arm64/kernel/vmlinux.lds:1: syntax error

In preparation for an arm64-private asm/rwonce.h implementation, which
will end up pulling assembly macros into linux/compiler.h, reduce the
number of headers we include directly and transitively in vmlinux.lds.S

Signed-off-by: Will Deacon 
---
 arch/arm64/include/asm/kernel-pgtable.h |  2 +-
 arch/arm64/include/asm/memory.h | 11 ++-
 arch/arm64/include/asm/uaccess.h|  1 +
 arch/arm64/kernel/entry.S   |  1 +
 arch/arm64/kernel/vmlinux.lds.S |  1 -
 arch/arm64/kvm/hyp-init.S   |  1 +
 6 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/include/asm/kernel-pgtable.h 
b/arch/arm64/include/asm/kernel-pgtable.h
index 3bf626f6fe0c..329fb15f6bac 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -8,7 +8,7 @@
 #ifndef __ASM_KERNEL_PGTABLE_H
 #define __ASM_KERNEL_PGTABLE_H
 
-#include 
+#include 
 #include 
 
 /*
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index a1871bb32bb1..9d4bf58cf7b3 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -10,11 +10,8 @@
 #ifndef __ASM_MEMORY_H
 #define __ASM_MEMORY_H
 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 /*
@@ -157,11 +154,15 @@
 #endif
 
 #ifndef __ASSEMBLY__
-extern u64 vabits_actual;
-#define PAGE_END   (_PAGE_END(vabits_actual))
 
 #include 
+#include 
 #include 
+#include 
+#include 
+
+extern u64 vabits_actual;
+#define PAGE_END   (_PAGE_END(vabits_actual))
 
 extern s64 physvirt_offset;
 extern s64 memstart_addr;
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index bc5c7b091152..8d7c466f809b 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -19,6 +19,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 5304d193c79d..b668aad3b762 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 5423ffe0a987..ec8e894684a7 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
index 6e6ed5581eed..076544393c3c 100644
--- a/arch/arm64/kvm/hyp-init.S
+++ b/arch/arm64/kvm/hyp-init.S
@@ -6,6 +6,7 @@
 
 #include 
 
+#include 
 #include 
 #include 
 #include 
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 10/19] Documentation/barriers: Remove references to [smp_]read_barrier_depends()

2020-07-10 Thread Will Deacon
The [smp_]read_barrier_depends() barrier macros no longer exist as
part of the Linux memory model, so remove all references to them from
the Documentation/ directory.

Although this is fairly mechanical on the whole, we drop the "CACHE
COHERENCY" section entirely from 'memory-barriers.txt' as it doesn't
make any sense now that the dependency barriers have been removed.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 .../RCU/Design/Requirements/Requirements.rst  |   2 +-
 Documentation/memory-barriers.txt | 156 +-
 2 files changed, 9 insertions(+), 149 deletions(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst 
b/Documentation/RCU/Design/Requirements/Requirements.rst
index 75b8ca007a11..50d5c43c48b0 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.rst
+++ b/Documentation/RCU/Design/Requirements/Requirements.rst
@@ -463,7 +463,7 @@ again without disrupting RCU readers.
 This guarantee was only partially premeditated. DYNIX/ptx used an
 explicit memory barrier for publication, but had nothing resembling
 ``rcu_dereference()`` for subscription, nor did it have anything
-resembling the ``smp_read_barrier_depends()`` that was later subsumed
+resembling the dependency-ordering barrier that was later subsumed
 into ``rcu_dereference()`` and later still into ``READ_ONCE()``. The
 need for these operations made itself known quite suddenly at a
 late-1990s meeting with the DEC Alpha architects, back in the days when
diff --git a/Documentation/memory-barriers.txt 
b/Documentation/memory-barriers.txt
index eaabc3134294..4e55aba3eb4a 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -553,12 +553,12 @@ There are certain things that the Linux kernel memory 
barriers do not guarantee:
 DATA DEPENDENCY BARRIERS (HISTORICAL)
 -
 
-As of v4.15 of the Linux kernel, an smp_read_barrier_depends() was
-added to READ_ONCE(), which means that about the only people who
-need to pay attention to this section are those working on DEC Alpha
-architecture-specific code and those working on READ_ONCE() itself.
-For those who need it, and for those who are interested in the history,
-here is the story of data-dependency barriers.
+As of v4.15 of the Linux kernel, an smp_mb() was added to READ_ONCE() for
+DEC Alpha, which means that about the only people who need to pay attention
+to this section are those working on DEC Alpha architecture-specific code
+and those working on READ_ONCE() itself.  For those who need it, and for
+those who are interested in the history, here is the story of
+data-dependency barriers.
 
 The usage requirements of data dependency barriers are a little subtle, and
 it's not always obvious that they're needed.  To illustrate, consider the
@@ -2708,144 +2708,6 @@ the properties of the memory window through which 
devices are accessed and/or
 the use of any special device communication instructions the CPU may have.
 
 
-CACHE COHERENCY

-
-Life isn't quite as simple as it may appear above, however: for while the
-caches are expected to be coherent, there's no guarantee that that coherency
-will be ordered.  This means that while changes made on one CPU will
-eventually become visible on all CPUs, there's no guarantee that they will
-become apparent in the same order on those other CPUs.
-
-
-Consider dealing with a system that has a pair of CPUs (1 & 2), each of which
-has a pair of parallel data caches (CPU 1 has A/B, and CPU 2 has C/D):
-
-   :
-   :  ++
-   :  +-+ ||
-   ++  : +--->| Cache A |<--->||
-   ||  : |+-+ ||
-   |  CPU 1 |<---+||
-   ||  : |+-+ ||
-   ++  : +--->| Cache B |<--->||
-   :  +-+ ||
-   :  | Memory |
-   :  +-+ | System |
-   ++  : +--->| Cache C |<--->||
-   ||  : |+-+ ||
-   |  CPU 2 |<---+||
-   ||  : |+-+ ||
-   ++  : +--->| Cache D |<--->||
-   :  +-+ ||
-   :  ++
-   :
-
-Imagine the system has the following properties:
-
- (*) an odd-numbered cache line may be in cache A, cache C or it may still be
- resident in memory;
-
- (*) an even-numbered cache line may be in cache B, cache D or it may still be
- resident in memory;
-
- (*) while the CPU core is interrogating one cache, the other cache may be
- making use of the bus to access the rest of the sys

[PATCH 00/18] Allow architectures to override __READ_ONCE()

2020-07-10 Thread Will Deacon
Hi all,

This is version three of the patches I previously posted here:

  v1: https://lore.kernel.org/lkml/20191108170120.22331-1-w...@kernel.org/
  v2: https://lore.kernel.org/r/20200630173734.14057-1-w...@kernel.org

Changes since v2 include:

  * Actually add the barrier in READ_ONCE() for Alpha!
  * Implement Alpha's smp_load_acquire() using __READ_ONCE(), rather than
the other way around.
  * Further untangling of header files
  * Use CONFIG_LTO instead of CONFIG_CLANG_LTO

I have booted this on arm64, and build-tested as follows:

  - arm64   allnoconfig, defconfig (also bisected) and allmodconfig
  - arm32   allnoconfig, defconfig and allmodconfig
  - x86_64  allnoconfig, defconfig and allmodcofig
  - alpha   defconfig, defconfig+CONFIG_SMP=y
  - riscv64 defconfig
  - powerpc64   defconfig
  - s390defconfig
  - sparc32 defconfig, defconfig+CONFIG_SMP=y
  - sparc64 defconfig

Cheers,

Will

Cc: Joel Fernandes 
Cc: Sami Tolvanen 
Cc: Nick Desaulniers 
Cc: Kees Cook 
Cc: Marco Elver 
Cc: "Paul E. McKenney" 
Cc: Matt Turner 
Cc: Ivan Kokshaysky 
Cc: Richard Henderson 
Cc: Peter Zijlstra 
Cc: Alan Stern 
Cc: "Michael S. Tsirkin" 
Cc: Jason Wang 
Cc: Arnd Bergmann 
Cc: Boqun Feng 
Cc: Catalin Marinas 
Cc: Mark Rutland 
Cc: linux-arm-ker...@lists.infradead.org>
Cc: linux-al...@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: kernel-t...@android.com

--->8

SeongJae Park (1):
  Documentation/barriers/kokr: Remove references to
[smp_]read_barrier_depends()

Will Deacon (18):
  tools: bpf: Use local copy of headers including uapi/linux/filter.h
  compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h
  asm/rwonce: Allow __READ_ONCE to be overridden by the architecture
  alpha: Override READ_ONCE() with barriered implementation
  asm/rwonce: Remove smp_read_barrier_depends() invocation
  asm/rwonce: Don't pull  into 'asm-generic/rwonce.h'
  vhost: Remove redundant use of read_barrier_depends() barrier
  alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()
  locking/barriers: Remove definitions for [smp_]read_barrier_depends()
  Documentation/barriers: Remove references to
[smp_]read_barrier_depends()
  tools/memory-model: Remove smp_read_barrier_depends() from informal
doc
  include/linux: Remove smp_read_barrier_depends() from comments
  checkpatch: Remove checks relating to [smp_]read_barrier_depends()
  arm64: Reduce the number of header files pulled into vmlinux.lds.S
  arm64: alternatives: Split up alternative.h
  arm64: cpufeatures: Add capability for LDAPR instruction
  arm64: alternatives: Remove READ_ONCE() usage during patch operation
  arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y

 .../RCU/Design/Requirements/Requirements.rst  |   2 +-
 Documentation/memory-barriers.txt | 156 +-
 .../translations/ko_KR/memory-barriers.txt| 146 +
 arch/alpha/include/asm/atomic.h   |  16 +-
 arch/alpha/include/asm/barrier.h  |  59 +---
 arch/alpha/include/asm/pgtable.h  |  10 +-
 arch/alpha/include/asm/rwonce.h   |  35 +++
 arch/arm/include/asm/vdso/gettimeofday.h  |   1 +
 arch/arm64/Kconfig|   3 +
 arch/arm64/include/asm/alternative-macros.h   | 276 ++
 arch/arm64/include/asm/alternative.h  | 267 +
 arch/arm64/include/asm/cpucaps.h  |   3 +-
 arch/arm64/include/asm/insn.h |   3 +-
 arch/arm64/include/asm/kernel-pgtable.h   |   2 +-
 arch/arm64/include/asm/memory.h   |  11 +-
 arch/arm64/include/asm/rwonce.h   |  63 
 arch/arm64/include/asm/uaccess.h  |   1 +
 .../include/asm/vdso/compat_gettimeofday.h|   1 +
 arch/arm64/include/asm/vdso/gettimeofday.h|   1 +
 arch/arm64/kernel/alternative.c   |   7 +-
 arch/arm64/kernel/cpufeature.c|  10 +
 arch/arm64/kernel/entry.S |   1 +
 arch/arm64/kernel/vdso/Makefile   |   2 +-
 arch/arm64/kernel/vdso32/Makefile |   2 +-
 arch/arm64/kernel/vmlinux.lds.S   |   1 -
 arch/arm64/kvm/hyp-init.S |   1 +
 arch/riscv/include/asm/vdso/gettimeofday.h|   1 +
 drivers/vhost/vhost.c |   5 -
 include/asm-generic/Kbuild|   1 +
 include/asm-generic/barrier.h |  19 +-
 include/asm-generic/rwonce.h  |  80 +
 include/linux/compiler.h  |  83 +-
 include/linux/nospec.h|   2 +
 include/linux/percpu-refcount.h   |   2 +-
 include/linux/ptr_ring.h  |   2 +-
 mm/memory.c   |   2 +-
 scripts/checkpatch.pl |   9 +-
 tools/bpf/Makefile|   3 +-
 tools/include/uapi/linux/filter.h |  90 ++
 .../Documentation/

[PATCH v3 08/19] alpha: Replace smp_read_barrier_depends() usage with smp_[r]mb()

2020-07-10 Thread Will Deacon
In preparation for removing smp_read_barrier_depends() altogether,
move the Alpha code over to using smp_rmb() and smp_mb() directly.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 arch/alpha/include/asm/atomic.h  | 16 
 arch/alpha/include/asm/pgtable.h | 10 +-
 mm/memory.c  |  2 +-
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/alpha/include/asm/atomic.h b/arch/alpha/include/asm/atomic.h
index 2144530d1428..2f8f7e54792f 100644
--- a/arch/alpha/include/asm/atomic.h
+++ b/arch/alpha/include/asm/atomic.h
@@ -16,10 +16,10 @@
 
 /*
  * To ensure dependency ordering is preserved for the _relaxed and
- * _release atomics, an smp_read_barrier_depends() is unconditionally
- * inserted into the _relaxed variants, which are used to build the
- * barriered versions. Avoid redundant back-to-back fences in the
- * _acquire and _fence versions.
+ * _release atomics, an smp_mb() is unconditionally inserted into the
+ * _relaxed variants, which are used to build the barriered versions.
+ * Avoid redundant back-to-back fences in the _acquire and _fence
+ * versions.
  */
 #define __atomic_acquire_fence()
 #define __atomic_post_full_fence()
@@ -70,7 +70,7 @@ static inline int atomic_##op##_return_relaxed(int i, 
atomic_t *v)\
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result)\
:"Ir" (i), "m" (v->counter) : "memory");\
-   smp_read_barrier_depends(); \
+   smp_mb();   \
return result;  \
 }
 
@@ -88,7 +88,7 @@ static inline int atomic_fetch_##op##_relaxed(int i, atomic_t 
*v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result)\
:"Ir" (i), "m" (v->counter) : "memory");\
-   smp_read_barrier_depends(); \
+   smp_mb();   \
return result;  \
 }
 
@@ -123,7 +123,7 @@ static __inline__ s64 atomic64_##op##_return_relaxed(s64 i, 
atomic64_t * v) \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result)\
:"Ir" (i), "m" (v->counter) : "memory");\
-   smp_read_barrier_depends(); \
+   smp_mb();   \
return result;  \
 }
 
@@ -141,7 +141,7 @@ static __inline__ s64 atomic64_fetch_##op##_relaxed(s64 i, 
atomic64_t * v)  \
".previous" \
:"=&r" (temp), "=m" (v->counter), "=&r" (result)\
:"Ir" (i), "m" (v->counter) : "memory");\
-   smp_read_barrier_depends(); \
+   smp_mb();   \
return result;  \
 }
 
diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgtable.h
index 162c17b2631f..660b14ce1317 100644
--- a/arch/alpha/include/asm/pgtable.h
+++ b/arch/alpha/include/asm/pgtable.h
@@ -277,9 +277,9 @@ extern inline pte_t pte_mkdirty(pte_t pte)  { pte_val(pte) 
|= __DIRTY_BITS; retur
 extern inline pte_t pte_mkyoung(pte_t pte) { pte_val(pte) |= 
__ACCESS_BITS; return pte; }
 
 /*
- * The smp_read_barrier_depends() in the following functions are required to
- * order the load of *dir (the pointer in the top level page table) with any
- * subsequent load of the returned pmd_t *ret (ret is data dependent on *dir).
+ * The smp_rmb() in the following functions are required to order the load of
+ * *dir (the pointer in the top level page table) with any subsequent load of
+ * the returned pmd_t *ret (ret is data dependent on *dir).
  *
  * If this ordering is not enforced, the CPU might load an older value of
  * *ret, which may be uninitialized data. See mm/memory.c:__pte_alloc for
@@ -293,7 +293,7 @@ extern inline pte_t pte_mkyoung(pte_t pte)  { pte_val(pte) 
|= __ACCESS_BITS; retu
 extern inline pmd_t * pmd_offset(pud_t * dir, unsigned long address)
 {
pmd_t *ret = (pmd_t *) pud_page_vaddr(*dir) + ((address >> PMD_SHIFT) & 
(PTRS_PER_PAGE - 1));
-   smp_read_barrier_depends(); /* see above */
+   smp_rmb(); /* see above */
return ret;
 }
 #define pmd_offset pmd_offset
@@ -303,7 +303,7 @@ extern inline pte_t * pte_offset_kernel(pmd_t * dir, 
unsigned long address)
 {
pte_t *ret = (pte_t *) pmd_page_vaddr(*dir)
  

[PATCH v3 01/19] tools: bpf: Use local copy of headers including uapi/linux/filter.h

2020-07-10 Thread Will Deacon
Pulling header files directly out of the kernel sources for inclusion in
userspace programs is highly error prone, not least because it bypasses
the kbuild infrastructure entirely and so may end up referencing other
header files that have not been generated.

Subsequent patches will cause compiler.h to pull in the ungenerated
asm/rwonce.h file via filter.h, breaking the build for tools/bpf:

  | $ make -C tools/bpf
  | make: Entering directory '/linux/tools/bpf'
  |   CC   bpf_jit_disasm.o
  |   LINK bpf_jit_disasm
  |   CC   bpf_dbg.o
  | In file included from /linux/include/uapi/linux/filter.h:9,
  |  from /linux/tools/bpf/bpf_dbg.c:41:
  | /linux/include/linux/compiler.h:247:10: fatal error: asm/rwonce.h: No such 
file or directory
  |  #include 
  |   ^~
  | compilation terminated.
  | make: *** [Makefile:61: bpf_dbg.o] Error 1
  | make: Leaving directory '/linux/tools/bpf'

Take a copy of the installed version of linux/filter.h  (i.e. the one
created by the 'headers_install' target) into tools/include/uapi/linux/
and adjust the BPF tool Makefile to reference the local include
directories instead of those in the main source tree.

Cc: Masahiro Yamada 
Acked-by: Alexei Starovoitov 
Suggested-by: Daniel Borkmann 
Reported-by: Xiao Yang 
Signed-off-by: Will Deacon 
---
 tools/bpf/Makefile|  3 +-
 tools/include/uapi/linux/filter.h | 90 +++
 2 files changed, 92 insertions(+), 1 deletion(-)
 create mode 100644 tools/include/uapi/linux/filter.h

diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index 6df1850f8353..8a69258fd8aa 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -9,7 +9,8 @@ MAKE = make
 INSTALL ?= install
 
 CFLAGS += -Wall -O2
-CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
+CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/tools/include/uapi \
+ -I$(srctree)/tools/include
 
 # This will work when bpf is built in tools env. where srctree
 # isn't set and when invoked from selftests build, where srctree
diff --git a/tools/include/uapi/linux/filter.h 
b/tools/include/uapi/linux/filter.h
new file mode 100644
index ..eaef459e7bd4
--- /dev/null
+++ b/tools/include/uapi/linux/filter.h
@@ -0,0 +1,90 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Linux Socket Filter Data Structures
+ */
+
+#ifndef __LINUX_FILTER_H__
+#define __LINUX_FILTER_H__
+
+
+#include 
+#include 
+
+/*
+ * Current version of the filter code architecture.
+ */
+#define BPF_MAJOR_VERSION 1
+#define BPF_MINOR_VERSION 1
+
+/*
+ * Try and keep these values and structures similar to BSD, especially
+ * the BPF code definitions which need to match so you can share filters
+ */
+ 
+struct sock_filter {   /* Filter block */
+   __u16   code;   /* Actual filter code */
+   __u8jt; /* Jump true */
+   __u8jf; /* Jump false */
+   __u32   k;  /* Generic multiuse field */
+};
+
+struct sock_fprog {/* Required for SO_ATTACH_FILTER. */
+   unsigned short  len;/* Number of filter blocks */
+   struct sock_filter *filter;
+};
+
+/* ret - BPF_K and BPF_X also apply */
+#define BPF_RVAL(code)  ((code) & 0x18)
+#define BPF_A   0x10
+
+/* misc */
+#define BPF_MISCOP(code) ((code) & 0xf8)
+#define BPF_TAX 0x00
+#define BPF_TXA 0x80
+
+/*
+ * Macros for filter block array initializers.
+ */
+#ifndef BPF_STMT
+#define BPF_STMT(code, k) { (unsigned short)(code), 0, 0, k }
+#endif
+#ifndef BPF_JUMP
+#define BPF_JUMP(code, k, jt, jf) { (unsigned short)(code), jt, jf, k }
+#endif
+
+/*
+ * Number of scratch memory words for: BPF_ST and BPF_STX
+ */
+#define BPF_MEMWORDS 16
+
+/* RATIONALE. Negative offsets are invalid in BPF.
+   We use them to reference ancillary data.
+   Unlike introduction new instructions, it does not break
+   existing compilers/optimizers.
+ */
+#define SKF_AD_OFF(-0x1000)
+#define SKF_AD_PROTOCOL 0
+#define SKF_AD_PKTTYPE 4
+#define SKF_AD_IFINDEX 8
+#define SKF_AD_NLATTR  12
+#define SKF_AD_NLATTR_NEST 16
+#define SKF_AD_MARK20
+#define SKF_AD_QUEUE   24
+#define SKF_AD_HATYPE  28
+#define SKF_AD_RXHASH  32
+#define SKF_AD_CPU 36
+#define SKF_AD_ALU_XOR_X   40
+#define SKF_AD_VLAN_TAG44
+#define SKF_AD_VLAN_TAG_PRESENT 48
+#define SKF_AD_PAY_OFFSET  52
+#define SKF_AD_RANDOM  56
+#define SKF_AD_VLAN_TPID   60
+#define SKF_AD_MAX 64
+
+#define SKF_NET_OFF(-0x10)
+#define SKF_LL_OFF (-0x20)
+
+#define BPF_NET_OFFSKF_NET_OFF
+#define BPF_LL_OFF SKF_LL_OFF
+
+#endif /* __LINUX_FILTER_H__ */
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 06/19] asm/rwonce: Don't pull into 'asm-generic/rwonce.h'

2020-07-10 Thread Will Deacon
Now that 'smp_read_barrier_depends()' has gone the way of the Norwegian
Blue, drop the inclusion of  in 'asm-generic/rwonce.h'.

This requires fixups to some architecture vdso headers which were
previously relying on 'asm/barrier.h' coming in via 'linux/compiler.h'.

Signed-off-by: Will Deacon 
---
 arch/arm/include/asm/vdso/gettimeofday.h  | 1 +
 arch/arm64/include/asm/vdso/compat_gettimeofday.h | 1 +
 arch/arm64/include/asm/vdso/gettimeofday.h| 1 +
 arch/riscv/include/asm/vdso/gettimeofday.h| 1 +
 include/asm-generic/rwonce.h  | 2 --
 include/linux/nospec.h| 2 ++
 6 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/vdso/gettimeofday.h 
b/arch/arm/include/asm/vdso/gettimeofday.h
index 36dc18553ed8..1b207cf07697 100644
--- a/arch/arm/include/asm/vdso/gettimeofday.h
+++ b/arch/arm/include/asm/vdso/gettimeofday.h
@@ -7,6 +7,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 #include 
 #include 
diff --git a/arch/arm64/include/asm/vdso/compat_gettimeofday.h 
b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
index b6907ae78e53..bcf764a4 100644
--- a/arch/arm64/include/asm/vdso/compat_gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/compat_gettimeofday.h
@@ -7,6 +7,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 #include 
 
diff --git a/arch/arm64/include/asm/vdso/gettimeofday.h 
b/arch/arm64/include/asm/vdso/gettimeofday.h
index afba6ba332f8..127fa63893e2 100644
--- a/arch/arm64/include/asm/vdso/gettimeofday.h
+++ b/arch/arm64/include/asm/vdso/gettimeofday.h
@@ -7,6 +7,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 
 #define VDSO_HAS_CLOCK_GETRES  1
diff --git a/arch/riscv/include/asm/vdso/gettimeofday.h 
b/arch/riscv/include/asm/vdso/gettimeofday.h
index c8e818688ec1..3099362d9f26 100644
--- a/arch/riscv/include/asm/vdso/gettimeofday.h
+++ b/arch/riscv/include/asm/vdso/gettimeofday.h
@@ -4,6 +4,7 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index cc810f1f18ca..cd0302746fb4 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -26,8 +26,6 @@
 #include 
 #include 
 
-#include 
-
 /*
  * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
  * atomicity. Note that this may result in tears!
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index 0c5ef54fd416..c1e79f72cd89 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -5,6 +5,8 @@
 
 #ifndef _LINUX_NOSPEC_H
 #define _LINUX_NOSPEC_H
+
+#include 
 #include 
 
 struct task_struct;
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 05/19] asm/rwonce: Remove smp_read_barrier_depends() invocation

2020-07-10 Thread Will Deacon
Alpha overrides __READ_ONCE() directly, so there's no need to use
smp_read_barrier_depends() in the core code. This also means that
__READ_ONCE() can be relied upon to provide dependency ordering.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 include/asm-generic/rwonce.h | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index f9dfa88fc04d..cc810f1f18ca 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -30,24 +30,16 @@
 
 /*
  * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
- * atomicity or dependency ordering guarantees. Note that this may result
- * in tears!
+ * atomicity. Note that this may result in tears!
  */
 #ifndef __READ_ONCE
 #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
 #endif
 
-#define __READ_ONCE_SCALAR(x)  \
-({ \
-   __unqual_scalar_typeof(x) __x = __READ_ONCE(x); \
-   smp_read_barrier_depends(); \
-   (typeof(x))__x; \
-})
-
 #define READ_ONCE(x)   \
 ({ \
compiletime_assert_rwonce_type(x);  \
-   __READ_ONCE_SCALAR(x);  \
+   __READ_ONCE(x); \
 })
 
 #define __WRITE_ONCE(x, val)   \
@@ -74,12 +66,9 @@ unsigned long __read_once_word_nocheck(const void *addr)
  */
 #define READ_ONCE_NOCHECK(x)   \
 ({ \
-   unsigned long __x;  \
-   compiletime_assert(sizeof(x) == sizeof(__x),\
+   compiletime_assert(sizeof(x) == sizeof(unsigned long),  \
"Unsupported access size for READ_ONCE_NOCHECK().");\
-   __x = __read_once_word_nocheck(&(x));   \
-   smp_read_barrier_depends(); \
-   (typeof(x))__x; \
+   (typeof(x))__read_once_word_nocheck(&(x));  \
 })
 
 static __no_kasan_or_inline
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 03/19] asm/rwonce: Allow __READ_ONCE to be overridden by the architecture

2020-07-10 Thread Will Deacon
The meat and potatoes of READ_ONCE() is defined by the __READ_ONCE()
macro, which uses a volatile casts in an attempt to avoid tearing of
byte, halfword, word and double-word accesses. Allow this to be
overridden by the architecture code in the case that things like memory
barriers are also required.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 include/asm-generic/rwonce.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
index 92cc2f223cb3..f9dfa88fc04d 100644
--- a/include/asm-generic/rwonce.h
+++ b/include/asm-generic/rwonce.h
@@ -33,7 +33,9 @@
  * atomicity or dependency ordering guarantees. Note that this may result
  * in tears!
  */
+#ifndef __READ_ONCE
 #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
+#endif
 
 #define __READ_ONCE_SCALAR(x)  \
 ({ \
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 07/19] vhost: Remove redundant use of read_barrier_depends() barrier

2020-07-10 Thread Will Deacon
Since commit 76ebbe78f739 ("locking/barriers: Add implicit
smp_read_barrier_depends() to READ_ONCE()"), there is no need to use
smp_read_barrier_depends() outside of the Alpha architecture code.

Unfortunately, there is precisely _one_ user in the vhost code, and
there isn't an obvious READ_ONCE() access making the barrier
redundant. However, on closer inspection (thanks, Jason), it appears
that vring synchronisation between the producer and consumer occurs via
the 'avail_idx' field, which is followed up by an rmb() in
vhost_get_vq_desc(), making the read_barrier_depends() redundant on
Alpha.

Jason says:

  | I'm also confused about the barrier here, basically in driver side
  | we did:
  |
  | 1) allocate pages
  | 2) store pages in indirect->addr
  | 3) smp_wmb()
  | 4) increase the avail idx (somehow a tail pointer of vring)
  |
  | in vhost we did:
  |
  | 1) read avail idx
  | 2) smp_rmb()
  | 3) read indirect->addr
  | 4) read from indirect->addr
  |
  | It looks to me even the data dependency barrier is not necessary
  | since we have rmb() which is sufficient for us to the correct
  | indirect->addr and driver are not expected to do any writing to
  | indirect->addr after avail idx is increased

Remove the redundant barrier invocation.

Suggested-by: Jason Wang 
Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 drivers/vhost/vhost.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index d7b8df3edffc..74d135ee7e26 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2092,11 +2092,6 @@ static int get_indirect(struct vhost_virtqueue *vq,
return ret;
}
iov_iter_init(&from, READ, vq->indirect, ret, len);
-
-   /* We will use the result as an address to read from, so most
-* architectures only need a compiler barrier here. */
-   read_barrier_depends();
-
count = len / sizeof desc;
/* Buffers are chained via a 16 bit next field, so
 * we can have at most 2^16 of these. */
-- 
2.27.0.383.g050319c2ae-goog

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v3 02/19] compiler.h: Split {READ, WRITE}_ONCE definitions out into rwonce.h

2020-07-10 Thread Will Deacon
In preparation for allowing architectures to define their own
implementation of the READ_ONCE() macro, move the generic
{READ,WRITE}_ONCE() definitions out of the unwieldy 'linux/compiler.h'
file and into a new 'rwonce.h' header under 'asm-generic'.

Acked-by: Paul E. McKenney 
Signed-off-by: Will Deacon 
---
 include/asm-generic/Kbuild|  1 +
 include/asm-generic/barrier.h |  2 +-
 include/asm-generic/rwonce.h  | 91 +++
 include/linux/compiler.h  | 83 +---
 4 files changed, 95 insertions(+), 82 deletions(-)
 create mode 100644 include/asm-generic/rwonce.h

diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
index 44ec80e70518..74b0612601dd 100644
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -45,6 +45,7 @@ mandatory-y += pci.h
 mandatory-y += percpu.h
 mandatory-y += pgalloc.h
 mandatory-y += preempt.h
+mandatory-y += rwonce.h
 mandatory-y += sections.h
 mandatory-y += serial.h
 mandatory-y += shmparam.h
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 2eacaf7d62f6..8116744bb82c 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -13,7 +13,7 @@
 
 #ifndef __ASSEMBLY__
 
-#include 
+#include 
 
 #ifndef nop
 #define nop()  asm volatile ("nop")
diff --git a/include/asm-generic/rwonce.h b/include/asm-generic/rwonce.h
new file mode 100644
index ..92cc2f223cb3
--- /dev/null
+++ b/include/asm-generic/rwonce.h
@@ -0,0 +1,91 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Prevent the compiler from merging or refetching reads or writes. The
+ * compiler is also forbidden from reordering successive instances of
+ * READ_ONCE and WRITE_ONCE, but only when the compiler is aware of some
+ * particular ordering. One way to make the compiler aware of ordering is to
+ * put the two invocations of READ_ONCE or WRITE_ONCE in different C
+ * statements.
+ *
+ * These two macros will also work on aggregate data types like structs or
+ * unions.
+ *
+ * Their two major use cases are: (1) Mediating communication between
+ * process-level code and irq/NMI handlers, all running on the same CPU,
+ * and (2) Ensuring that the compiler does not fold, spindle, or otherwise
+ * mutilate accesses that either do not require ordering or that interact
+ * with an explicit memory barrier or atomic instruction that provides the
+ * required ordering.
+ */
+#ifndef __ASM_GENERIC_RWONCE_H
+#define __ASM_GENERIC_RWONCE_H
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
+ * atomicity or dependency ordering guarantees. Note that this may result
+ * in tears!
+ */
+#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
+
+#define __READ_ONCE_SCALAR(x)  \
+({ \
+   __unqual_scalar_typeof(x) __x = __READ_ONCE(x); \
+   smp_read_barrier_depends(); \
+   (typeof(x))__x; \
+})
+
+#define READ_ONCE(x)   \
+({ \
+   compiletime_assert_rwonce_type(x);  \
+   __READ_ONCE_SCALAR(x);  \
+})
+
+#define __WRITE_ONCE(x, val)   \
+do {   \
+   *(volatile typeof(x) *)&(x) = (val);\
+} while (0)
+
+#define WRITE_ONCE(x, val) \
+do {   \
+   compiletime_assert_rwonce_type(x);  \
+   __WRITE_ONCE(x, val);   \
+} while (0)
+
+static __no_sanitize_or_inline
+unsigned long __read_once_word_nocheck(const void *addr)
+{
+   return __READ_ONCE(*(unsigned long *)addr);
+}
+
+/*
+ * Use READ_ONCE_NOCHECK() instead of READ_ONCE() if you need to load a
+ * word from memory atomically but without telling KASAN/KCSAN. This is
+ * usually used by unwinding code when walking the stack of a running process.
+ */
+#define READ_ONCE_NOCHECK(x)   \
+({ \
+   unsigned long __x;  \
+   compiletime_assert(sizeof(x) == sizeof(__x),\
+   "Unsupported access size for READ_ONCE_NOCHECK().");\
+   __x = __read_once_word_nocheck(&(x));   \
+   smp_read_barrier_depends(); \
+   (typeof(x))__x;

Re: [PATCH] virtio_balloon: clear modern features under legacy

2020-07-10 Thread Alexander Duyck
On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin  wrote:
>
> Page reporting features were never supported by legacy hypervisors.
> Supporting them poses a problem: should we use native endian-ness (like
> current code assumes)? Or little endian-ness like the virtio spec says?
> Rather than try to figure out, and since results of
> incorrect endian-ness are dire, let's just block this configuration.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michael S. Tsirkin 

So I am not sure about the patch description. In the case of page
poison and free page reporting I don't think we are defining anything
that doesn't already have a definition of how to use in legacy.
Specifically the virtio_balloon_config is already defined as having
all fields as little endian in legacy mode, and there is a definition
for all of the fields in a virtqueue and how they behave in legacy
mode.

As far as I can see the only item that may be an issue is the command
ID being supplied via the virtqueue for free page hinting, which
appears to be in native endian-ness. Otherwise it would have fallen
into the same category since it is making use of virtio_balloon_config
and a virtqueue for supplying the page location and length.

> ---
>  drivers/virtio/virtio_balloon.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 5d4b891bf84f..b9bc03345157 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device 
> *vdev)
>
>  static int virtballoon_validate(struct virtio_device *vdev)
>  {
> +   /*
> +* Legacy devices never specified how modern features should behave.
> +* E.g. which endian-ness to use? Better not to assume anything.
> +*/
> +   if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
> +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> +   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
> +   }
> /*
>  * Inform the hypervisor that our pages are poisoned or
>  * initialized. If we cannot do that then we should disable

The patch content itself I am fine with since odds are nobody would
expect to use these features with a legacy device.

Acked-by: Alexander Duyck 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH V6 4/5] iommu/dma-iommu: Use the dev->coherent_dma_mask

2020-07-10 Thread Christoph Hellwig
Btw, what is the current state of converting intel-iommu to the dma-iommu
code?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] vsock/virtio: annotate 'the_virtio_vsock' RCU pointer

2020-07-10 Thread Stefano Garzarella
Commit 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free
on the_virtio_vsock") starts to use RCU to protect 'the_virtio_vsock'
pointer, but we forgot to annotate it.

This patch adds the annotation to fix the following sparse errors:

net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:207:17: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:561:13: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:612:9: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:631:9: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock [noderef] 
__rcu *
net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock *

Fixes: 0deab087b16a ("vsock/virtio: use RCU to avoid use-after-free on 
the_virtio_vsock")
Reported-by: Michael S. Tsirkin 
Signed-off-by: Stefano Garzarella 
---
 net/vmw_vsock/virtio_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transport.c
index dfbaf6bd8b1c..2700a63ab095 100644
--- a/net/vmw_vsock/virtio_transport.c
+++ b/net/vmw_vsock/virtio_transport.c
@@ -22,7 +22,7 @@
 #include 
 
 static struct workqueue_struct *virtio_vsock_workqueue;
-static struct virtio_vsock *the_virtio_vsock;
+static struct virtio_vsock __rcu *the_virtio_vsock;
 static DEFINE_MUTEX(the_virtio_vsock_mutex); /* protects the_virtio_vsock */
 
 struct virtio_vsock {
-- 
2.26.2

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] virtio_balloon: clear modern features under legacy

2020-07-10 Thread David Hildenbrand
On 10.07.20 13:31, Michael S. Tsirkin wrote:
> Page reporting features were never supported by legacy hypervisors.
> Supporting them poses a problem: should we use native endian-ness (like
> current code assumes)? Or little endian-ness like the virtio spec says?
> Rather than try to figure out, and since results of
> incorrect endian-ness are dire, let's just block this configuration.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/virtio/virtio_balloon.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 5d4b891bf84f..b9bc03345157 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device 
> *vdev)
>  
>  static int virtballoon_validate(struct virtio_device *vdev)
>  {
> + /*
> +  * Legacy devices never specified how modern features should behave.
> +  * E.g. which endian-ness to use? Better not to assume anything.
> +  */
> + if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
> + __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
> + __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> + __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
> + }
>   /*
>* Inform the hypervisor that our pages are poisoned or
>* initialized. If we cannot do that then we should disable
> 

Very right

Acked-by: David Hildenbrand 

-- 
Thanks,

David / dhildenb

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] virtio_balloon: clear modern features under legacy

2020-07-10 Thread Michael S. Tsirkin
Page reporting features were never supported by legacy hypervisors.
Supporting them poses a problem: should we use native endian-ness (like
current code assumes)? Or little endian-ness like the virtio spec says?
Rather than try to figure out, and since results of
incorrect endian-ness are dire, let's just block this configuration.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_balloon.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 5d4b891bf84f..b9bc03345157 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -1107,6 +1107,15 @@ static int virtballoon_restore(struct virtio_device 
*vdev)
 
 static int virtballoon_validate(struct virtio_device *vdev)
 {
+   /*
+* Legacy devices never specified how modern features should behave.
+* E.g. which endian-ness to use? Better not to assume anything.
+*/
+   if (!virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
+   __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_REPORTING);
+   }
/*
 * Inform the hypervisor that our pages are poisoned or
 * initialized. If we cannot do that then we should disable
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] virtio_balloon: fix sparse warning

2020-07-10 Thread David Hildenbrand
On 10.07.20 12:48, Michael S. Tsirkin wrote:
> balloon uses virtio32_to_cpu instead of cpu_to_virtio32
> to convert a native endian number to virtio.
> No practical difference but makes sparse warn.
> Fix it up.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  drivers/virtio/virtio_balloon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index fc7301406540..5d4b891bf84f 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -596,7 +596,7 @@ static int send_cmd_id_start(struct virtio_balloon *vb)
>   while (virtqueue_get_buf(vq, &unused))
>   ;
>  
> - vb->cmd_id_active = virtio32_to_cpu(vb->vdev,
> + vb->cmd_id_active = cpu_to_virtio32(vb->vdev,
>   virtio_balloon_cmd_id_received(vb));
>   sg_init_one(&sg, &vb->cmd_id_active, sizeof(vb->cmd_id_active));
>   err = virtqueue_add_outbuf(vq, &sg, 1, &vb->cmd_id_active, GFP_KERNEL);
> 

Reviewed-by: David Hildenbrand 

-- 
Thanks,

David / dhildenb

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] virtio_balloon: fix sparse warning

2020-07-10 Thread Michael S. Tsirkin
balloon uses virtio32_to_cpu instead of cpu_to_virtio32
to convert a native endian number to virtio.
No practical difference but makes sparse warn.
Fix it up.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/virtio/virtio_balloon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index fc7301406540..5d4b891bf84f 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -596,7 +596,7 @@ static int send_cmd_id_start(struct virtio_balloon *vb)
while (virtqueue_get_buf(vq, &unused))
;
 
-   vb->cmd_id_active = virtio32_to_cpu(vb->vdev,
+   vb->cmd_id_active = cpu_to_virtio32(vb->vdev,
virtio_balloon_cmd_id_received(vb));
sg_init_one(&sg, &vb->cmd_id_active, sizeof(vb->cmd_id_active));
err = virtqueue_add_outbuf(vq, &sg, 1, &vb->cmd_id_active, GFP_KERNEL);
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] virtio_ring: sparse warning fixup

2020-07-10 Thread Michael S. Tsirkin
virtio_store_mb was built with split ring in mind so it accepts
__virtio16 arguments. Packed ring uses __le16 values, so sparse
complains.  It's just a store with some barriers so let's convert it to
a macro, we don't loose too much type safety by doing that.

Signed-off-by: Michael S. Tsirkin 
---
 include/linux/virtio_ring.h | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
index 3dc70adfe5f5..b485b13fa50b 100644
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -46,16 +46,15 @@ static inline void virtio_wmb(bool weak_barriers)
dma_wmb();
 }
 
-static inline void virtio_store_mb(bool weak_barriers,
-  __virtio16 *p, __virtio16 v)
-{
-   if (weak_barriers) {
-   virt_store_mb(*p, v);
-   } else {
-   WRITE_ONCE(*p, v);
-   mb();
-   }
-}
+#define virtio_store_mb(weak_barriers, p, v) \
+do { \
+   if (weak_barriers) { \
+   virt_store_mb(*p, v); \
+   } else { \
+   WRITE_ONCE(*p, v); \
+   mb(); \
+   } \
+} while (0) \
 
 struct virtio_device;
 struct virtqueue;
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] vhost/scsi: fix up req type endian-ness

2020-07-10 Thread Michael S. Tsirkin
vhost/scsi doesn't handle type conversion correctly
for request type when using virtio 1.0 and up for BE,
or cross-endian platforms.

Fix it up using vhost_32_to_cpu.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael S. Tsirkin 
---
 drivers/vhost/scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 6fb4d7ecfa19..b22adf03f584 100644
--- a/drivers/vhost/scsi.c
+++ b/drivers/vhost/scsi.c
@@ -1215,7 +1215,7 @@ vhost_scsi_ctl_handle_vq(struct vhost_scsi *vs, struct 
vhost_virtqueue *vq)
continue;
}
 
-   switch (v_req.type) {
+   switch (vhost32_to_cpu(vq, v_req.type)) {
case VIRTIO_SCSI_T_TMF:
vc.req = &v_req.tmf;
vc.req_size = sizeof(struct virtio_scsi_ctrl_tmf_req);
-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: sparse warnings in net/vmw_vsock/virtio_transport.c

2020-07-10 Thread Stefano Garzarella
On Fri, Jul 10, 2020 at 06:24:51AM -0400, Michael S. Tsirkin wrote:
> RCU trickery:
> 
> net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:207:17: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:561:13: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:612:9: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock *
> net/vmw_vsock/virtio_transport.c:631:9: error: incompatible types in 
> comparison expression (different address spaces):
> net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock [noderef] 
> __rcu *
> net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock *
>   CC [M]  net/vmw_vsock/virtio_transport.o
> 
> can you take a look at fixing this pls?

Thanks for reporting!

We should annotate 'the_virtio_vsock' with __rcu.

I'll send a patch to fix these warnings.

Thanks,
Stefano

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


sparse warnings in net/vmw_vsock/virtio_transport.c

2020-07-10 Thread Michael S. Tsirkin
RCU trickery:

net/vmw_vsock/virtio_transport.c:73:17: error: incompatible types in comparison 
expression (different address spaces):
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock [noderef] __rcu *
net/vmw_vsock/virtio_transport.c:73:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:171:17: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock [noderef] __rcu 
*
net/vmw_vsock/virtio_transport.c:171:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:207:17: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock [noderef] __rcu 
*
net/vmw_vsock/virtio_transport.c:207:17:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:561:13: error: incompatible types in 
comparison expression (different address spaces):
net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock [noderef] __rcu 
*
net/vmw_vsock/virtio_transport.c:561:13:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:612:9: error: incompatible types in comparison 
expression (different address spaces):
net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock [noderef] __rcu *
net/vmw_vsock/virtio_transport.c:612:9:struct virtio_vsock *
net/vmw_vsock/virtio_transport.c:631:9: error: incompatible types in comparison 
expression (different address spaces):
net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock [noderef] __rcu *
net/vmw_vsock/virtio_transport.c:631:9:struct virtio_vsock *
  CC [M]  net/vmw_vsock/virtio_transport.o

can you take a look at fixing this pls?

-- 
MST

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH] scsi: virtio_scsi: Remove unnecessary condition checks

2020-07-10 Thread Paolo Bonzini
On 10/07/20 09:40, Markus Elfring wrote:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/virtio_scsi.c?id=42f82040ee66db13525dc6f14b8559890b2f4c1c#n980
>>>
>>> if (!virtscsi_cmd_cache) {
>>> pr_err("kmem_cache_create() for virtscsi_cmd_cache failed\n");
>>> -   goto error;
>>> +   return -ENOMEM;
>>> }
>>
>> Could be doable, but I don't see a particular benefit.
> 
> Can a bit more “compliance” (with the Linux coding style) matter here?

No.

>> Having a single error loop is an advantage by itself.
> 
> I do not see that a loop is involved in the implementation of the function 
> “init”.

s/loop/label/ sorry.

Paolo

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] scsi: virtio_scsi: Remove unnecessary condition checks

2020-07-10 Thread Paolo Bonzini
On 10/07/20 08:32, Markus Elfring wrote:
 +  mempool_destroy(virtscsi_cmd_pool);
 +  virtscsi_cmd_pool = NULL;
 +  kmem_cache_destroy(virtscsi_cmd_cache);
 +  virtscsi_cmd_cache = NULL;
return ret;
  }
>>>
>>> How do you think about to add a jump target so that the execution
>>> of a few statements can be avoided according to a previous
>>> null pointer check?
>>
>> The point of the patch is precisely to simplify the code,
> 
> I suggest to reconsider also Linux coding style aspects
> for the implementation of the function “init”.
> https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/scsi/virtio_scsi.c#L980
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/scsi/virtio_scsi.c?id=42f82040ee66db13525dc6f14b8559890b2f4c1c#n980
> 
>   if (!virtscsi_cmd_cache) {
>   pr_err("kmem_cache_create() for virtscsi_cmd_cache failed\n");
> - goto error;
> + return -ENOMEM;
>   }

Could be doable, but I don't see a particular benefit.  Having a single
error loop is an advantage by itself.

The coding style is a suggestion.  Note the difference between

kfree(foo->bar);
kfree(foo);

and

kfree(bar);
kfree(foo);

> See also:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=42f82040ee66db13525dc6f14b8559890b2f4c1c#n461
> 
> 
>> executing a couple more instruction is not an issue.
> 
> With which update steps would like to achieve such a code variant?
> 
> destroy_pool:
>   mempool_destroy(virtscsi_cmd_pool);
>   virtscsi_cmd_pool = NULL;
> destroy_cache:
>   kmem_cache_destroy(virtscsi_cmd_cache);
>   virtscsi_cmd_cache = NULL;
>   return ret;

... while there's no advantage in this.

Paolo

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization