build warning in drivers/macintosh/rack-meter.c

[Stephen Rothwell]

Hi all,

These warnings have beeen around for a while now;

drivers/macintosh/rack-meter.c:157:2: warning: 'memset' used with length equal 
to number of elements without multiplication by element size [-Wmemset-elt-size]
  memset(rdma->buf1, 0, ARRAY_SIZE(rdma->buf1));
  ^~
drivers/macintosh/rack-meter.c:158:2: warning: 'memset' used with length equal 
to number of elements without multiplication by element size [-Wmemset-elt-size]
  memset(rdma->buf2, 0, ARRAY_SIZE(rdma->buf2));
  ^~

Introduced by commit

  4f7bef7a9f69 ("drivers: macintosh: rack-meter: fix bogus memsets")

I guess updating to a newer compiler has started generating these.

-- 
Cheers,
Stephen Rothwell


pgpjAbt07i2K0.pgp
Description: OpenPGP digital signature

Re: [PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

[Nicholas Piggin]

On Thu, 15 Mar 2018 20:15:52 +0100
Michal Suchanek  wrote:

> On powerpc syscall entry is done in assembly so patch in an explicit
> barrier_nospec.

Same comment as Linus for this -- the barriers are before the branch here,
so is it possible the branch instruction can be speculative while the index
is used to load the syscall table?

Thanks,
Nick

> 
> Signed-off-by: Michal Suchanek 
> ---
>  arch/powerpc/kernel/entry_64.S | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 2cb5109a7ea3..7bfc4cf48af2 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -36,6 +36,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #ifdef CONFIG_PPC_BOOK3S
>  #include 
> @@ -159,6 +160,7 @@ system_call:  /* label this so stack 
> traces look sane */
>   andi.   r11,r10,_TIF_SYSCALL_DOTRACE
>   bne .Lsyscall_dotrace   /* does not return */
>   cmpldi  0,r0,NR_syscalls
> + barrier_nospec
>   bge-.Lsyscall_enosys
>  
>  .Lsyscall:
> @@ -319,6 +321,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>   ld  r10,TI_FLAGS(r10)
>  
>   cmpldi  r0,NR_syscalls
> + barrier_nospec
>   blt+.Lsyscall
>  
>   /* Return code is already in r3 thanks to do_syscall_trace_enter() */

Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown

[Benjamin Herrenschmidt]

On Wed, 2018-03-14 at 17:58 +0100, Frederic Barrat wrote:
> +   if (irq == hw_irq) {
> +   cur &= 1 << 31;
> +   cur |= XIVE_BAD_IRQ;
> +   *(q->qpage + idx) = cpu_to_be32(cur);
> +   }
> +
> +   idx = (idx + 1) & q->msk;
> +   if (idx == 0)
> +   toggle ^= 1;
> +   } while (irq && (count < q->msk));

Safer to make the replacement an atomic with cmpxhg just in case you
found an old one trailing the queue that's just getting updated by HW.

Cheers,
Ben.

Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown

[Benjamin Herrenschmidt]

On Wed, 2018-03-14 at 18:47 +0100, Cédric Le Goater wrote:
> We could also loop on the ESB 'P' bit to wait for the irqs to be handled,
> using :
> 
> xive_esb_read(irq, XIVE_ESB_GET)
> 
> which has no side effect. It looks simpler to me. Is that possible ? 

But you can race with something sending another one... I prefer the
guarantee that after final masking, we check the queue contents on
shutdown.

That will be solid vs. other type of interrupts as well.

Cheers,
Ben.

Re: [PATCH RFC rebase 2/9] powerpc: Use barrier_nospec in copy_from_user

[Linus Torvalds]

On Thu, Mar 15, 2018 at 12:15 PM, Michal Suchanek  wrote:
> This is based on x86 patch doing the same.
>
> Signed-off-by: Michal Suchanek 
> ---
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -258,8 +259,10 @@ do { 
>   \
> long __gu_err = -EFAULT;\
> unsigned long  __gu_val = 0;\
> const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
> +   int can_access = access_ok(VERIFY_READ, __gu_addr, (size)); \
> might_fault();  \
> -   if (access_ok(VERIFY_READ, __gu_addr, (size)))  \
> +   barrier_nospec();   \
> +   if (can_access) \
> __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
> (x) = (__force __typeof__(*(ptr)))__gu_val;   
>   \
> __gu_err;   \

Is the above really correct? The barrier is *before* the conditional
branch that might be mis-predicted.

I don't know how the ppc barrier works, but that sounds completely bogus.

   Linus

Re: [PATCH v3 1/5] rfi-flush: Move the logic to avoid a redo into the debugfs code

[Murilo Opsfelder Araujo]

On 03/14/2018 07:40 PM, Mauricio Faria de Oliveira wrote:
> From: Michael Ellerman 
> 
> rfi_flush_enable() includes a check to see if we're already
> enabled (or disabled), and in that case does nothing.
> 
> But that means calling setup_rfi_flush() a 2nd time doesn't actually
> work, which is a bit confusing.
> 
> Move that check into the debugfs code, where it really belongs.
> 
> Signed-off-by: Michael Ellerman 
> Signed-off-by: Mauricio Faria de Oliveira 
> ---
>  arch/powerpc/kernel/setup_64.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index c388cc3..3efc01a 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -846,9 +846,6 @@ static void do_nothing(void *unused)
> 
>  void rfi_flush_enable(bool enable)
>  {
> - if (rfi_flush == enable)
> - return;
> -
>   if (enable) {
>   do_rfi_flush_fixups(enabled_flush_types);
>   on_each_cpu(do_nothing, NULL, 1);
> @@ -902,13 +899,19 @@ void __init setup_rfi_flush(enum l1d_flush_type types, 
> bool enable)
>  #ifdef CONFIG_DEBUG_FS
>  static int rfi_flush_set(void *data, u64 val)
>  {
> + bool enable;
> +
>   if (val == 1)
> - rfi_flush_enable(true);
> + enable = true;
>   else if (val == 0)
> - rfi_flush_enable(false);
> + enable = false;
>   else
>   return -EINVAL;
> 
> + /* Only do anything if we're changing state */
> + if (enable != rfi_flush)

Hi, Mauricio.

Do we need to take into account if no_rfi_flush == true?

if ((enable != rfi_flush) && !no_rfi_flush)

> + rfi_flush_enable(enable);
> +
>   return 0;
>  }
> 

Cheers
Murilo

[PATCH RFC rebase 8/9] powerpc/64s: barrier_nospec: Add hcall triggerr

[Michal Suchanek]

Adapted from the RFI implementation

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/platforms/pseries/mobility.c |  2 +-
 arch/powerpc/platforms/pseries/pseries.h  |  2 +-
 arch/powerpc/platforms/pseries/setup.c| 37 ++-
 3 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/mobility.c 
b/arch/powerpc/platforms/pseries/mobility.c
index 8a8033a249c7..9d506be1580e 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -349,7 +349,7 @@ void post_mobility_fixup(void)
"failed: %d\n", rc);
 
/* Possibly switch to a new RFI flush type */
-   pseries_setup_rfi_flush();
+   pseries_setup_rfi_nospec();
 
return;
 }
diff --git a/arch/powerpc/platforms/pseries/pseries.h 
b/arch/powerpc/platforms/pseries/pseries.h
index 27cdcb69fd18..d49670c67686 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -100,6 +100,6 @@ static inline unsigned long cmo_get_page_size(void)
 
 int dlpar_workqueue_init(void);
 
-void pseries_setup_rfi_flush(void);
+void pseries_setup_rfi_nospec(void);
 
 #endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/setup.c 
b/arch/powerpc/platforms/pseries/setup.c
index 9877c3dfcdc8..4b899a4db6dd 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -459,30 +459,47 @@ static void __init find_and_init_phbs(void)
of_pci_check_probe_only();
 }
 
-void pseries_setup_rfi_flush(void)
+void pseries_setup_rfi_nospec(void)
 {
struct h_cpu_char_result result;
-   enum l1d_flush_type types;
-   bool enable;
+   enum l1d_flush_type flush_types;
+   enum spec_barrier_type barrier_type;
+   bool flush_enable;
+   bool barrier_enable;
long rc;
 
/* Enable by default */
-   enable = true;
-   types = L1D_FLUSH_FALLBACK;
+   flush_enable = true;
+   flush_types = L1D_FLUSH_FALLBACK;
+   barrier_enable = true;
+   /* no fallback available if the firmware does not tell us */
+   barrier_type = SPEC_BARRIER_NONE;
 
rc = plpar_get_cpu_characteristics();
if (rc == H_SUCCESS) {
if (result.character & H_CPU_CHAR_L1D_FLUSH_TRIG2)
-   types |= L1D_FLUSH_MTTRIG;
+   flush_types |= L1D_FLUSH_MTTRIG;
if (result.character & H_CPU_CHAR_L1D_FLUSH_ORI30)
-   types |= L1D_FLUSH_ORI;
+   flush_types |= L1D_FLUSH_ORI;
+   if (result.character & H_CPU_CHAR_SPEC_BAR_ORI31)
+   barrier_type |= SPEC_BARRIER_ORI;
 
if ((!(result.behaviour & H_CPU_BEHAV_L1D_FLUSH_PR)) ||
(!(result.behaviour & H_CPU_BEHAV_FAVOUR_SECURITY)))
-   enable = false;
+   flush_enable = false;
+   /*
+* Do not check H_CPU_BEHAV_BNDS_CHK_SPEC_BAR - the ORI does
+* nothing anyway when not supported.
+*/
+   if ((!(result.behaviour & H_CPU_BEHAV_FAVOUR_SECURITY)))
+   barrier_enable = false;
+   } else {
+   /* Default to fallback if case hcall is not available */
+   flush_types = L1D_FLUSH_FALLBACK;
}
 
-   setup_rfi_flush(types, enable);
+   setup_barrier_nospec(barrier_type, barrier_enable);
+   setup_rfi_flush(flush_types, flush_enable);
 }
 
 #ifdef CONFIG_PCI_IOV
@@ -658,7 +675,7 @@ static void __init pSeries_setup_arch(void)
 
fwnmi_init();
 
-   pseries_setup_rfi_flush();
+   pseries_setup_rfi_nospec();
 
/* By default, only probe PCI (can be overridden by rtas_pci) */
pci_add_flags(PCI_PROBE_ONLY);
-- 
2.13.6

[PATCH RFC rebase 9/9] powerpc/64: barrier_nospec: Add commandline trigger

[Michal Suchanek]

Add commandline options spectre_v2 and nospectre_v2

These are named same as similar x86 options regardless of actual effect
to not require platform-specific configuration.

Supported options:
nospectre_v2 or spectre_v2=off - speculation barrier not used
spectre_v2=on or spectre_v2=auto - speculation barrier used

Changing the settings after boot is not supported and VM migration may
change requirements so auto is same as on.

Based on s390 implementation

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/kernel/setup_64.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f6678a7b6114..c74e656265df 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -840,6 +840,28 @@ static int __init handle_no_pti(char *p)
 }
 early_param("nopti", handle_no_pti);
 
+static int __init nospectre_v2_setup_early(char *str)
+{
+   no_nospec = true;
+   return 0;
+}
+early_param("nospectre_v2", nospectre_v2_setup_early);
+
+static int __init spectre_v2_setup_early(char *str)
+{
+   if (str && !strncmp(str, "on", 2))
+   no_nospec = false;
+
+   if (str && !strncmp(str, "off", 3))
+   no_nospec = true;
+
+   if (str && !strncmp(str, "auto", 4))
+   no_nospec = false;
+
+   return 0;
+}
+early_param("spectre_v2", spectre_v2_setup_early);
+
 static void do_nothing(void *unused)
 {
/*
-- 
2.13.6

[PATCH RFC rebase 7/9] powerpc/64: barrier_nospec: Add debugfs trigger

[Michal Suchanek]

Copypasta from rfi implementation

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/kernel/setup_64.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index f60e0e3b5ad2..f6678a7b6114 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -963,6 +963,41 @@ static __init int rfi_flush_debugfs_init(void)
return 0;
 }
 device_initcall(rfi_flush_debugfs_init);
+
+static int barrier_nospec_set(void *data, u64 val)
+{
+   switch (val) {
+   case 0:
+   case 1:
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   if (!!val == !!barrier_nospec_enabled)
+   return 0;
+
+   barrier_nospec_enable(!!val);
+
+   return 0;
+}
+
+static int barrier_nospec_get(void *data, u64 *val)
+{
+   *val = barrier_nospec_enabled ? 1 : 0;
+   return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(fops_barrier_nospec,
+   barrier_nospec_get, barrier_nospec_set, "%llu\n");
+
+static __init int barrier_nospec_debugfs_init(void)
+{
+   debugfs_create_file("barrier_nospec", 0600, powerpc_debugfs_root, NULL,
+   _barrier_nospec);
+   return 0;
+}
+device_initcall(barrier_nospec_debugfs_init);
 #endif
 
 ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute *attr, 
char *buf)
-- 
2.13.6

[PATCH RFC rebase 5/9] powerpc/64s: Add support for ori barrier_nospec patching

[Michal Suchanek]

Based on the RFI patching. This is required to be able to disable the
speculation barrier.

Only one barrier type is supported and it does nothing when the firmware
does not enable it. Also re-patching modules is not supported So the
only meaningful thing that can be done is patching out the speculation
barrier at boot when the user says it is not wanted.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/include/asm/barrier.h|  4 ++--
 arch/powerpc/include/asm/feature-fixups.h |  9 +
 arch/powerpc/include/asm/setup.h  |  8 
 arch/powerpc/kernel/setup_64.c| 30 ++
 arch/powerpc/kernel/vmlinux.lds.S |  7 +++
 arch/powerpc/lib/feature-fixups.c | 27 +++
 6 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 8e47b3abe405..4079a95e84c2 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -75,9 +75,9 @@ do {  
\
___p1;  \
 })
 
-/* TODO: add patching so this can be disabled */
 /* Prevent speculative execution past this barrier. */
-#define barrier_nospec_asm ori 31,31,0
+#define barrier_nospec_asm SPEC_BARRIER_FIXUP_SECTION; \
+   nop
 #ifdef __ASSEMBLY__
 #define barrier_nospec barrier_nospec_asm
 #else
diff --git a/arch/powerpc/include/asm/feature-fixups.h 
b/arch/powerpc/include/asm/feature-fixups.h
index 1e82eb3caabd..9d3382618ffd 100644
--- a/arch/powerpc/include/asm/feature-fixups.h
+++ b/arch/powerpc/include/asm/feature-fixups.h
@@ -195,11 +195,20 @@ label##3: \
FTR_ENTRY_OFFSET 951b-952b; \
.popsection;
 
+#define SPEC_BARRIER_FIXUP_SECTION \
+953:   \
+   .pushsection __spec_barrier_fixup,"a";  \
+   .align 2;   \
+954:   \
+   FTR_ENTRY_OFFSET 953b-954b; \
+   .popsection;
+
 
 #ifndef __ASSEMBLY__
 #include 
 
 extern long __start___rfi_flush_fixup, __stop___rfi_flush_fixup;
+extern long __start___spec_barrier_fixup, __stop___spec_barrier_fixup;
 
 void apply_feature_fixups(void);
 void setup_feature_keys(void);
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index bbcdf929be54..c7e9e66c2a38 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -49,8 +49,16 @@ enum l1d_flush_type {
L1D_FLUSH_MTTRIG= 0x8,
 };
 
+/* These are bit flags */
+enum spec_barrier_type {
+   SPEC_BARRIER_NONE   = 0x1,
+   SPEC_BARRIER_ORI= 0x2,
+};
+
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
+void setup_barrier_nospec(enum spec_barrier_type, bool enable);
+void do_barrier_nospec_fixups(enum spec_barrier_type type);
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4ec4a27b36a9..767240074cad 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -815,6 +815,10 @@ static enum l1d_flush_type enabled_flush_types;
 static void *l1d_flush_fallback_area;
 static bool no_rfi_flush;
 bool rfi_flush;
+enum spec_barrier_type powerpc_barrier_nospec;
+static enum spec_barrier_type barrier_nospec_type;
+static bool no_nospec;
+bool barrier_nospec_enabled;
 
 static int __init handle_no_rfi_flush(char *p)
 {
@@ -900,6 +904,32 @@ void setup_rfi_flush(enum l1d_flush_type types, bool 
enable)
rfi_flush_enable(enable);
 }
 
+void barrier_nospec_enable(bool enable)
+{
+   barrier_nospec_enabled = enable;
+
+   if (enable) {
+   powerpc_barrier_nospec = barrier_nospec_type;
+   do_barrier_nospec_fixups(powerpc_barrier_nospec);
+   on_each_cpu(do_nothing, NULL, 1);
+   } else {
+   powerpc_barrier_nospec = SPEC_BARRIER_NONE;
+   do_barrier_nospec_fixups(powerpc_barrier_nospec);
+   }
+}
+
+void setup_barrier_nospec(enum spec_barrier_type type, bool enable)
+{
+   /*
+* Only one barrier type is supported and it does nothing when the
+* firmware does not enable it. So the only meaningful thing to do
+* here is check the user preference.
+*/
+   barrier_nospec_type = SPEC_BARRIER_ORI;
+
+   barrier_nospec_enable(!no_nospec && enable);
+}
+
 #ifdef CONFIG_DEBUG_FS
 static int rfi_flush_set(void *data, u64 val)
 {
diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index c8af90ff49f0..744b58ff77f1 100644
--- 

[PATCH RFC rebase 6/9] powerpc/64: Patch barrier_nospec in modules

[Michal Suchanek]

Note that unlike RFI which is patched only in kernel the nospec state
reflects settings at the time the module was loaded.

Iterating all modules and re-patching every time the settings change is
not implemented.

Based on lwsync patching.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/include/asm/setup.h  |  5 -
 arch/powerpc/kernel/module.c  |  6 ++
 arch/powerpc/kernel/setup_64.c|  4 ++--
 arch/powerpc/lib/feature-fixups.c | 17 ++---
 4 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index c7e9e66c2a38..92520d2483b8 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -58,7 +58,10 @@ enum spec_barrier_type {
 void setup_rfi_flush(enum l1d_flush_type, bool enable);
 void do_rfi_flush_fixups(enum l1d_flush_type types);
 void setup_barrier_nospec(enum spec_barrier_type, bool enable);
-void do_barrier_nospec_fixups(enum spec_barrier_type type);
+void do_barrier_nospec_fixups_kernel(enum spec_barrier_type type);
+void do_barrier_nospec_fixups(enum spec_barrier_type type,
+ void *start, void *end);
+extern enum spec_barrier_type powerpc_barrier_nospec;
 
 #endif /* !__ASSEMBLY__ */
 
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index 3f7ba0f5bf29..7b6d0ec06a21 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -72,6 +72,12 @@ int module_finalize(const Elf_Ehdr *hdr,
do_feature_fixups(powerpc_firmware_features,
  (void *)sect->sh_addr,
  (void *)sect->sh_addr + sect->sh_size);
+
+   sect = find_section(hdr, sechdrs, "__spec_barrier_fixup");
+   if (sect != NULL)
+   do_barrier_nospec_fixups(powerpc_barrier_nospec,
+ (void *)sect->sh_addr,
+ (void *)sect->sh_addr + sect->sh_size);
 #endif
 
sect = find_section(hdr, sechdrs, "__lwsync_fixup");
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 767240074cad..f60e0e3b5ad2 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -910,11 +910,11 @@ void barrier_nospec_enable(bool enable)
 
if (enable) {
powerpc_barrier_nospec = barrier_nospec_type;
-   do_barrier_nospec_fixups(powerpc_barrier_nospec);
+   do_barrier_nospec_fixups_kernel(powerpc_barrier_nospec);
on_each_cpu(do_nothing, NULL, 1);
} else {
powerpc_barrier_nospec = SPEC_BARRIER_NONE;
-   do_barrier_nospec_fixups(powerpc_barrier_nospec);
+   do_barrier_nospec_fixups_kernel(powerpc_barrier_nospec);
}
 }
 
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index dfeb7feeccef..a529ac6b2a5d 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -160,14 +160,15 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
: "unknown");
 }
 
-void do_barrier_nospec_fixups(enum spec_barrier_type type)
+void do_barrier_nospec_fixups(enum spec_barrier_type type,
+ void *fixup_start, void *fixup_end)
 {
unsigned int instr, *dest;
long *start, *end;
int i;
 
-   start = PTRRELOC(&__start___spec_barrier_fixup),
-   end = PTRRELOC(&__stop___spec_barrier_fixup);
+   start = fixup_start;
+   end = fixup_end;
 
instr = 0x6000; /* nop */
 
@@ -186,6 +187,16 @@ void do_barrier_nospec_fixups(enum spec_barrier_type type)
printk(KERN_DEBUG "barrier-nospec: patched %d locations\n", i);
 }
 
+void do_barrier_nospec_fixups_kernel(enum spec_barrier_type type)
+{
+   void *start, *end;
+
+   start = PTRRELOC(&__start___spec_barrier_fixup),
+   end = PTRRELOC(&__stop___spec_barrier_fixup);
+
+   do_barrier_nospec_fixups(type, start, end);
+}
+
 #endif /* CONFIG_PPC_BOOK3S_64 */
 
 void do_lwsync_fixups(unsigned long value, void *fixup_start, void *fixup_end)
-- 
2.13.6

[PATCH RFC rebase 4/9] powerpc/64s: Use barrier_nospec in RFI_FLUSH_SLOT

[Michal Suchanek]

The RFI flush support patches the speculation barrier into
RFI_FLUSH_SLOT as part of the RFI flush. Use separate barrier_nospec
instead.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/include/asm/exception-64s.h | 2 +-
 arch/powerpc/lib/feature-fixups.c| 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/exception-64s.h 
b/arch/powerpc/include/asm/exception-64s.h
index 471b2274fbeb..bb5a3052b29b 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -81,9 +81,9 @@
  * L1-D cache when returning to userspace or a guest.
  */
 #define RFI_FLUSH_SLOT \
+   barrier_nospec_asm; \
RFI_FLUSH_FIXUP_SECTION;\
nop;\
-   nop;\
nop
 
 #define RFI_TO_KERNEL  \
diff --git a/arch/powerpc/lib/feature-fixups.c 
b/arch/powerpc/lib/feature-fixups.c
index 35f80ab7cbd8..4cc2f0c5c863 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -119,7 +119,7 @@ void do_feature_fixups(unsigned long value, void 
*fixup_start, void *fixup_end)
 #ifdef CONFIG_PPC_BOOK3S_64
 void do_rfi_flush_fixups(enum l1d_flush_type types)
 {
-   unsigned int instrs[3], *dest;
+   unsigned int instrs[2], *dest;
long *start, *end;
int i;
 
@@ -128,15 +128,13 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
 
instrs[0] = 0x6000; /* nop */
instrs[1] = 0x6000; /* nop */
-   instrs[2] = 0x6000; /* nop */
 
if (types & L1D_FLUSH_FALLBACK)
-   /* b .+16 to fallback flush */
-   instrs[0] = 0x4810;
+   /* b .+12 to fallback flush */
+   instrs[0] = 0x480c;
 
i = 0;
if (types & L1D_FLUSH_ORI) {
-   instrs[i++] = 0x63ff; /* ori 31,31,0 speculation barrier */
instrs[i++] = 0x63de; /* ori 30,30,0 L1d flush*/
}
 
@@ -150,7 +148,6 @@ void do_rfi_flush_fixups(enum l1d_flush_type types)
 
patch_instruction(dest, instrs[0]);
patch_instruction(dest + 1, instrs[1]);
-   patch_instruction(dest + 2, instrs[2]);
}
 
printk(KERN_DEBUG "rfi-flush: patched %d locations (%s flush)\n", i,
-- 
2.13.6

[PATCH RFC rebase 2/9] powerpc: Use barrier_nospec in copy_from_user

[Michal Suchanek]

This is based on x86 patch doing the same.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/include/asm/uaccess.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 51bfeb8777f0..af9b0e731f46 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -248,6 +248,7 @@ do {
\
__chk_user_ptr(ptr);\
if (!is_kernel_addr((unsigned long)__gu_addr))  \
might_fault();  \
+   barrier_nospec();   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err;   \
@@ -258,8 +259,10 @@ do {   
\
long __gu_err = -EFAULT;\
unsigned long  __gu_val = 0;\
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+   int can_access = access_ok(VERIFY_READ, __gu_addr, (size)); \
might_fault();  \
-   if (access_ok(VERIFY_READ, __gu_addr, (size)))  \
+   barrier_nospec();   \
+   if (can_access) \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; 
\
__gu_err;   \
@@ -271,6 +274,7 @@ do {
\
unsigned long __gu_val; \
const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr);\
+   barrier_nospec();   \
__get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__force __typeof__(*(ptr)))__gu_val; \
__gu_err;   \
@@ -298,15 +302,19 @@ static inline unsigned long raw_copy_from_user(void *to,
 
switch (n) {
case 1:
+   barrier_nospec();
__get_user_size(*(u8 *)to, from, 1, ret);
break;
case 2:
+   barrier_nospec();
__get_user_size(*(u16 *)to, from, 2, ret);
break;
case 4:
+   barrier_nospec();
__get_user_size(*(u32 *)to, from, 4, ret);
break;
case 8:
+   barrier_nospec();
__get_user_size(*(u64 *)to, from, 8, ret);
break;
}
@@ -314,6 +322,7 @@ static inline unsigned long raw_copy_from_user(void *to,
return 0;
}
 
+   barrier_nospec();
return __copy_tofrom_user((__force void __user *)to, from, n);
 }
 
-- 
2.13.6

[PATCH RFC rebase 3/9] powerpc/64: Use barrier_nospec in syscall entry

[Michal Suchanek]

On powerpc syscall entry is done in assembly so patch in an explicit
barrier_nospec.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/kernel/entry_64.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2cb5109a7ea3..7bfc4cf48af2 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_PPC_BOOK3S
 #include 
@@ -159,6 +160,7 @@ system_call:/* label this so stack 
traces look sane */
andi.   r11,r10,_TIF_SYSCALL_DOTRACE
bne .Lsyscall_dotrace   /* does not return */
cmpldi  0,r0,NR_syscalls
+   barrier_nospec
bge-.Lsyscall_enosys
 
 .Lsyscall:
@@ -319,6 +321,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
ld  r10,TI_FLAGS(r10)
 
cmpldi  r0,NR_syscalls
+   barrier_nospec
blt+.Lsyscall
 
/* Return code is already in r3 thanks to do_syscall_trace_enter() */
-- 
2.13.6

[PATCH RFC rebase 1/9] powerpc: Add barrier_nospec

[Michal Suchanek]

When the firmware supports it an otherwise useless combination of ORI
instruction arguments is interpreted as speculation barrier. Implement
barrier_nospec using this instruction.

Based on the out-of-tree gmb() implementation.

Signed-off-by: Michal Suchanek 
---
 arch/powerpc/include/asm/barrier.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 10daa1d56e0a..8e47b3abe405 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -75,6 +75,15 @@ do { 
\
___p1;  \
 })
 
+/* TODO: add patching so this can be disabled */
+/* Prevent speculative execution past this barrier. */
+#define barrier_nospec_asm ori 31,31,0
+#ifdef __ASSEMBLY__
+#define barrier_nospec barrier_nospec_asm
+#else
+#define barrier_nospec() __asm__ __volatile__ 
(stringify_in_c(barrier_nospec_asm) : : :)
+#endif
+
 #include 
 
 #endif /* _ASM_POWERPC_BARRIER_H */
-- 
2.13.6

[PATCH RFC rebase 0/9] powerpc barrier_nospec

[Michal Suchanek]

Yes, it is good idea to add some commit messages.

Also I rebased the patches on top v3 of series

Setup RFI flush after PowerVM LPM migration

Thanks

Michal

Michal Suchanek (9):
  powerpc: Add barrier_nospec
  powerpc: Use barrier_nospec in copy_from_user
  powerpc/64: Use barrier_nospec in syscall entry
  powerpc/64s: Use barrier_nospec in RFI_FLUSH_SLOT
  powerpc/64s: Add support for ori barrier_nospec patching
  powerpc/64: Patch barrier_nospec in modules
  powerpc/64: barrier_nospec: Add debugfs trigger
  powerpc/64s: barrier_nospec: Add hcall triggerr
  powerpc/64: barrier_nospec: Add commandline trigger

 arch/powerpc/include/asm/barrier.h|  9 
 arch/powerpc/include/asm/exception-64s.h  |  2 +-
 arch/powerpc/include/asm/feature-fixups.h |  9 
 arch/powerpc/include/asm/setup.h  | 11 
 arch/powerpc/include/asm/uaccess.h| 11 +++-
 arch/powerpc/kernel/entry_64.S|  3 ++
 arch/powerpc/kernel/module.c  |  6 +++
 arch/powerpc/kernel/setup_64.c| 87 +++
 arch/powerpc/kernel/vmlinux.lds.S |  7 +++
 arch/powerpc/lib/feature-fixups.c | 47 ++---
 arch/powerpc/platforms/pseries/mobility.c |  2 +-
 arch/powerpc/platforms/pseries/pseries.h  |  2 +-
 arch/powerpc/platforms/pseries/setup.c| 37 +
 13 files changed, 213 insertions(+), 20 deletions(-)

-- 
2.13.6

Re: [PATCH] powerpc: Use common error handling code in setup_new_fdt()

[Thiago Jung Bauermann]

Joe Perches  writes:

> On Thu, 2018-03-15 at 14:57 +0300, Dan Carpenter wrote:
>> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
>> > 
>> > SF Markus Elfring  writes:
>> > 
>> > > From: Markus Elfring 
>> > > Date: Sun, 11 Mar 2018 09:03:42 +0100
>> > > 
>> > > Add a jump target so that a bit of exception handling can be better 
>> > > reused
>> > > at the end of this function.
>> > > 
>> > > This issue was detected by using the Coccinelle software.
>> > > 
>> > > Signed-off-by: Markus Elfring 
>> > > ---
>> > >  arch/powerpc/kernel/machine_kexec_file_64.c | 28 
>> > > 
>> > >  1 file changed, 12 insertions(+), 16 deletions(-)
>> > 
>> > I liked it. Thanks!
>> > 
>> > Reviewed-by: Thiago Jung Bauermann 
>> > 
>> 
>> You know that compilers already re-use string constants so this doesn't
>> actually save memory?
>
> And modern compilers create their own jump labels
> so this doesn't change object code either?

IMHO it's an improvement to the source code itself. I wasn't thinking
about the object file.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center

Re: [PATCH v3] x86: treat pkey-0 special

[Ram Pai]

On Thu, Mar 15, 2018 at 10:31:51AM -0700, Dave Hansen wrote:
> On 03/15/2018 10:21 AM, Ram Pai wrote:
> > On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> >> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
>  +if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> >>> Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> >>> ever. If it does, then this wants to be fixed.
> >> I was thinking that we _do_ actually want it to seem allocated.  It just
> >> get "allocated" implicitly when an mm is created.  I think that will
> >> simplify the code if we avoid treating it specially in as many places as
> >> possible.
> > I think, the logic that makes pkey-0 special must to go
> > in arch-neutral code.   How about checking for pkey-0 in sys_pkey_free()
> > itself?
> 
> This is for protection against shooting yourself in the foot?  Yes, that
> can go in sys_pkey_free().
> 
> Does this need manpage and/or selftests updates?

Yes. it needs selftest, manpage and documentation updates too.

Unfortunately I am not getting enough reviewed-by for my selftests
and documentation changes. :-(  Need help!


-- 
Ram Pai

Re: [PATCH v3] x86: treat pkey-0 special

[Dave Hansen]

On 03/15/2018 10:21 AM, Ram Pai wrote:
> On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
>> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
 +  if (!pkey || !mm_pkey_is_allocated(mm, pkey))
>>> Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
>>> ever. If it does, then this wants to be fixed.
>> I was thinking that we _do_ actually want it to seem allocated.  It just
>> get "allocated" implicitly when an mm is created.  I think that will
>> simplify the code if we avoid treating it specially in as many places as
>> possible.
> I think, the logic that makes pkey-0 special must to go
> in arch-neutral code.   How about checking for pkey-0 in sys_pkey_free()
> itself?

This is for protection against shooting yourself in the foot?  Yes, that
can go in sys_pkey_free().

Does this need manpage and/or selftests updates?

Re: [PATCH v3] x86: treat pkey-0 special

[Ram Pai]

On Thu, Mar 15, 2018 at 08:55:31AM -0700, Dave Hansen wrote:
> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >> +  if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> > ever. If it does, then this wants to be fixed.
> 
> I was thinking that we _do_ actually want it to seem allocated.  It just
> get "allocated" implicitly when an mm is created.  I think that will
> simplify the code if we avoid treating it specially in as many places as
> possible.

I think, the logic that makes pkey-0 special must to go
in arch-neutral code.   How about checking for pkey-0 in sys_pkey_free()
itself?

RP

Re: [PATCH v8 0/6] add support for relative references in special sections

[Ard Biesheuvel]

On 11 March 2018 at 12:38, Ard Biesheuvel  wrote:
> This adds support for emitting special sections such as initcall arrays,
> PCI fixups and tracepoints as relative references rather than absolute
> references. This reduces the size by 50% on 64-bit architectures, but
> more importantly, it removes the need for carrying relocation metadata
> for these sections in relocatable kernels (e.g., for KASLR) that needs
> to be fixed up at boot time. On arm64, this reduces the vmlinux footprint
> of such a reference by 8x (8 byte absolute reference + 24 byte RELA entry
> vs 4 byte relative reference)
>
> Patch #3 was sent out before as a single patch. This series supersedes
> the previous submission. This version makes relative ksymtab entries
> dependent on the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS rather
> than trying to infer from kbuild test robot replies for which architectures
> it should be blacklisted.
>
> Patch #1 introduces the new Kconfig symbol HAVE_ARCH_PREL32_RELOCATIONS,
> and sets it for the main architectures that are expected to benefit the
> most from this feature, i.e., 64-bit architectures or ones that use
> runtime relocations.
>
> Patch #2 add support for #define'ing __DISABLE_EXPORTS to get rid of
> ksymtab/kcrctab sections in decompressor and EFI stub objects when
> rebuilding existing C files to run in a different context.
>
> Patches #4 - #6 implement relative references for initcalls, PCI fixups
> and tracepoints, respectively, all of which produce sections with order
> ~1000 entries on an arm64 defconfig kernel with tracing enabled. This
> means we save about 28 KB of vmlinux space for each of these patches.
>
> [From the v7 series blurb, which included the jump_label patches as well]:
>   For the arm64 kernel, all patches combined reduce the memory footprint of
>   vmlinux by about 1.3 MB (using a config copied from Ubuntu that has KASLR
>   enabled), of which ~1 MB is the size reduction of the RELA section in .init,
>   and the remaining 300 KB is reduction of .text/.data.
>
> Branch:
> git://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git 
> relative-special-sections-v8
>

All,

I think this has converged to a mergeable state now (taking the
mini-tweak for patch #3 into account I provided in a reply)

Are there any objections to this being merged?

Andrew,

If nobody objects, is this something you would care to pick up for the
next cycle? Do I need to respin to incorporate the mini-tweak and
apply Nico's ack to patch #2?

Thanks,
Ard.


> Changes since v7:
> - dropped the jump_label patches, these will be revisited in a separate series
> - reorder __DISABLE_EXPORTS with __KSYM_DEPS__ check in #2
> - use offset_to_ptr() helper function to abstract the relative pointer
>   conversion [int *off -> (ulong)off + *off] (#3 - #6)
> - rebase onto v4.16-rc3
>
> Changes since v6:
> - drop S390 from patch #1 introducing HAVE_ARCH_PREL32_RELOCATIONS: kbuild
>   robot threw me some s390 curveballs, and given that s390 does not define
>   CONFIG_RELOCATABLE in the first place, it does not benefit as much from
>   relative references as arm64, x86 and power do
> - add patch to allow symbol exports to be disabled at compilation unit
>   granularity (#2)
> - get rid of arm64 vmlinux.lds.S hunk to ensure code generated by 
> __ADDRESSABLE
>   gets discarded from the EFI stub - it is no longer needed after adding #2 
> (#1)
> - change _ADDRESSABLE() to emit a data reference, not a code reference - this
>   is another simplification made possible by patch #2 (#3)
> - add Steven's ack to #6
> - split x86 jump_label patch into two (#9, #10)
>
> Changes since v5:
> - add missing jump_label prototypes to s390 jump_label.h (#6)
> - fix inverted condition in call to jump_entry_is_module_init() (#6)
>
> Changes since v4:
> - add patches to convert x86 and arm64 to use relative references for jump
>   tables (#6 - #8)
> - rename PCI patch and add Bjorn's ack (#4)
> - rebase onto v4.15-rc5
>
> Changes since v3:
> - fix module unload issue in patch #5 reported by Jessica, by reusing the
>   updated routine for_each_tracepoint_range() for the quiescent check at
>   module unload time; this requires this routine to be moved before
>   tracepoint_module_going() in kernel/tracepoint.c
> - add Jessica's ack to #2
> - rebase onto v4.14-rc1
>
> Changes since v2:
> - Revert my slightly misguided attempt to appease checkpatch, which resulted
>   in needless churn and worse code. This v3 is based on v1 with a few tweaks
>   that were actually reasonable checkpatch warnings: unnecessary braces (as
>   pointed out by Ingo) and other minor whitespace misdemeanors.
>
> Changes since v1:
> - Remove checkpatch errors to the extent feasible: in some cases, this
>   involves moving extern declarations into C files, and switching to
>   struct definitions rather than typedefs. Some errors are impossible
>   to fix: please find the remaining ones after the diffstat.
> - Used 'int' 

Re: [PATCH v3] x86: treat pkey-0 special

[Thomas Gleixner]

On Thu, 15 Mar 2018, Dave Hansen wrote:

> On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
> >> +  if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> > Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> > ever. If it does, then this wants to be fixed.
> 
> I was thinking that we _do_ actually want it to seem allocated.  It just
> get "allocated" implicitly when an mm is created.  I think that will
> simplify the code if we avoid treating it specially in as many places as
> possible.

That works as well.

Re: [PATCH v3] x86: treat pkey-0 special

[Dave Hansen]

On 03/15/2018 02:46 AM, Thomas Gleixner wrote:
>> +if (!pkey || !mm_pkey_is_allocated(mm, pkey))
> Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
> ever. If it does, then this wants to be fixed.

I was thinking that we _do_ actually want it to seem allocated.  It just
get "allocated" implicitly when an mm is created.  I think that will
simplify the code if we avoid treating it specially in as many places as
possible.

Re: [PATCH] powerpc: Use common error handling code in setup_new_fdt()

[Dan Carpenter]

On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
> 
> SF Markus Elfring  writes:
> 
> > From: Markus Elfring 
> > Date: Sun, 11 Mar 2018 09:03:42 +0100
> >
> > Add a jump target so that a bit of exception handling can be better reused
> > at the end of this function.
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring 
> > ---
> >  arch/powerpc/kernel/machine_kexec_file_64.c | 28 
> > 
> >  1 file changed, 12 insertions(+), 16 deletions(-)
> 
> I liked it. Thanks!
> 
> Reviewed-by: Thiago Jung Bauermann 
> 

You know that compilers already re-use string constants so this doesn't
actually save memory?  Also we should be preserving the error codes
instead of always returning -EINVAL.

regards,
dan carpenter

Re: [PATCH 0/5] DPAA Ethernet fixes

[David Miller]

From: Madalin-cristian Bucur 
Date: Thu, 15 Mar 2018 09:32:35 +

>> -Original Message-
>> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
>> Sent: Wednesday, March 14, 2018 8:43 PM
>> To: da...@davemloft.net; Madalin-cristian Bucur
>> 
>> 
>> On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote:
>> > Hi,
>> >
>> > This patch set is addressing several issues in the DPAA Ethernet
>> > driver suite:
>> >
>> >  - module unload crash caused by wrong reference to device being left
>> >in the cleanup code after the DSA related changes
>> >  - scheduling wile atomic bug in QMan code revealed during dpaa_eth
>> >module unload
>> >  - a couple of error counter fixes, a duplicated init in dpaa_eth.
>> 
>> hmm, some of these(all?) bugs are in stable too, CC: stable perhaps?
> 
> Hi Jocke,
> 
> I did not check that, they should be added.

Networking patches are not queued to stable by CC:'ing stable.

Instead you just simply need to ask me explicitly for -stable submission
which I will do at the appropriate time after the fixes have been able
to cook in Linus's tree for a little while.

I've queued this series up for that purpose, thanks.

Re: [PATCH] powerpc: Use common error handling code in setup_new_fdt()

[Joe Perches]

On Thu, 2018-03-15 at 14:57 +0300, Dan Carpenter wrote:
> On Wed, Mar 14, 2018 at 06:22:07PM -0300, Thiago Jung Bauermann wrote:
> > 
> > SF Markus Elfring  writes:
> > 
> > > From: Markus Elfring 
> > > Date: Sun, 11 Mar 2018 09:03:42 +0100
> > > 
> > > Add a jump target so that a bit of exception handling can be better reused
> > > at the end of this function.
> > > 
> > > This issue was detected by using the Coccinelle software.
> > > 
> > > Signed-off-by: Markus Elfring 
> > > ---
> > >  arch/powerpc/kernel/machine_kexec_file_64.c | 28 
> > > 
> > >  1 file changed, 12 insertions(+), 16 deletions(-)
> > 
> > I liked it. Thanks!
> > 
> > Reviewed-by: Thiago Jung Bauermann 
> > 
> 
> You know that compilers already re-use string constants so this doesn't
> actually save memory?

And modern compilers create their own jump labels
so this doesn't change object code either?

Re: [PATCH v3] x86: treat pkey-0 special

[Thomas Gleixner]

On Wed, 14 Mar 2018, Ram Pai wrote:
> Applications need the ability to associate an address-range with some
> key and latter revert to its initial default key. Pkey-0 comes close to
> providing this function but falls short, because the current
> implementation disallows applications to explicitly associate pkey-0 to
> the address range.
> 
> This patch clarifies the semantics of pkey-0 and provides the

grep 'This patch' Documentation/process

> corresponding implementation on powerpc.
> 
> Pkey-0 is special with the following semantics.
> (a) it is implicitly allocated and can never be freed. It always exists.
> (b) it is the default key assigned to any address-range.
> (c) it can be explicitly associated with any address-range.
> 
> Tested on x86_64.

I'm curious how the corresponding implementation on powerpc can be tested
on x86_64. Copy and paste is not enough ...

> 
> History:
> v3 : added clarification of the semantics of pkey0.
>   -- suggested by Dave Hansen
> v2 : split the patch into two, one for x86 and one for powerpc
>   -- suggested by Michael Ellermen

Please put the history below the --- seperator. It's not part of the
changelog. That way the tools can discard it when picking up the patch.

> 
> cc: Dave Hansen 
> cc: Michael Ellermen 
> cc: Ingo Molnar 
> Signed-off-by: Ram Pai 
> ---
>  arch/x86/include/asm/pkeys.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
> index a0ba1ff..6ea7486 100644
> --- a/arch/x86/include/asm/pkeys.h
> +++ b/arch/x86/include/asm/pkeys.h
> @@ -52,7 +52,7 @@ bool mm_pkey_is_allocated(struct mm_struct *mm, int pkey)
>* from pkey_alloc().  pkey 0 is special, and never
>* returned from pkey_alloc().
>*/
> - if (pkey <= 0)
> + if (pkey < 0)
>   return false;
>   if (pkey >= arch_max_pkey())
>   return false;
> @@ -92,7 +92,8 @@ int mm_pkey_alloc(struct mm_struct *mm)
>  static inline
>  int mm_pkey_free(struct mm_struct *mm, int pkey)
>  {
> - if (!mm_pkey_is_allocated(mm, pkey))
> + /* pkey 0 is special and can never be freed */

This comment is pretty useless. How should anyone figure out whats special
about pkey 0?

> + if (!pkey || !mm_pkey_is_allocated(mm, pkey))

Why this extra check? mm_pkey_is_allocated(mm, 0) should not return true
ever. If it does, then this wants to be fixed.

Thanks,

tglx

RE: [PATCH 0/5] DPAA Ethernet fixes

[Madalin-cristian Bucur]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@infinera.com]
> Sent: Wednesday, March 14, 2018 8:43 PM
> To: da...@davemloft.net; Madalin-cristian Bucur
> 
> 
> On Wed, 2018-03-14 at 08:37 -0500, Madalin Bucur wrote:
> > Hi,
> >
> > This patch set is addressing several issues in the DPAA Ethernet
> > driver suite:
> >
> >  - module unload crash caused by wrong reference to device being left
> >in the cleanup code after the DSA related changes
> >  - scheduling wile atomic bug in QMan code revealed during dpaa_eth
> >module unload
> >  - a couple of error counter fixes, a duplicated init in dpaa_eth.
> 
> hmm, some of these(all?) bugs are in stable too, CC: stable perhaps?

Hi Jocke,

I did not check that, they should be added.

Thanks,
Madalin

> >
> > Madalin
> >
> > Camelia Groza (3):
> >   dpaa_eth: remove duplicate initialization
> >   dpaa_eth: increment the RX dropped counter when needed
> >   dpaa_eth: remove duplicate increment of the tx_errors counter
> >
> > Madalin Bucur (2):
> >   soc/fsl/qbman: fix issue in qman_delete_cgr_safe()
> >   dpaa_eth: fix error in dpaa_remove()
> >
> >  drivers/net/ethernet/freescale/dpaa/dpaa_eth.c |  8 
> >  drivers/soc/fsl/qbman/qman.c   | 28 
> > +-
> >  2 files changed, 9 insertions(+), 27 deletions(-)
> >
> > --
> > 2.1.0
> >

Re: more warnings

[Stephen Rothwell]

Hi Balbir,

On Thu, 15 Mar 2018 19:42:33 +1100 Balbir Singh  wrote:
>
> On Wed, Mar 14, 2018 at 4:23 PM, Stephen Rothwell  
> wrote:
> >
> > I also get these from a powerpc allyesconfig build of linux-next:
> >
> > WARNING: vmlinux.o(.text+0x7c81c): Section mismatch in reference from the 
> > function .stop_machine_change_mapping() to the function 
> > .meminit.text:.create_physical_mapping()
> > The function .stop_machine_change_mapping() references
> > the function __meminit .create_physical_mapping().
> > This is often because .stop_machine_change_mapping lacks a __meminit
> > annotation or the annotation of .create_physical_mapping is wrong.
> >
> > WARNING: vmlinux.o(.text+0x7c828): Section mismatch in reference from the 
> > function .stop_machine_change_mapping() to the function 
> > .meminit.text:.create_physical_mapping()
> > The function .stop_machine_change_mapping() references
> > the function __meminit .create_physical_mapping().
> > This is often because .stop_machine_change_mapping lacks a __meminit
> > annotation or the annotation of .create_physical_mapping is wrong.
> >  
> 
> Patches have been sent to fix this - http://patchwork.ozlabs.org/patch/883991/

Excellent, thanks.

-- 
Cheers,
Stephen Rothwell


pgpkZdoCaJkGF.pgp
Description: OpenPGP digital signature

Re: more warnings

[Balbir Singh]

On Wed, Mar 14, 2018 at 4:23 PM, Stephen Rothwell  wrote:
> Hi all,
>
> I also get these from a powerpc allyesconfig build of linux-next:
>
> WARNING: vmlinux.o(.text+0x7c81c): Section mismatch in reference from the 
> function .stop_machine_change_mapping() to the function 
> .meminit.text:.create_physical_mapping()
> The function .stop_machine_change_mapping() references
> the function __meminit .create_physical_mapping().
> This is often because .stop_machine_change_mapping lacks a __meminit
> annotation or the annotation of .create_physical_mapping is wrong.
>
> WARNING: vmlinux.o(.text+0x7c828): Section mismatch in reference from the 
> function .stop_machine_change_mapping() to the function 
> .meminit.text:.create_physical_mapping()
> The function .stop_machine_change_mapping() references
> the function __meminit .create_physical_mapping().
> This is often because .stop_machine_change_mapping lacks a __meminit
> annotation or the annotation of .create_physical_mapping is wrong.
>


Hi, Stephen

Patches have been sent to fix this - http://patchwork.ozlabs.org/patch/883991/

Balbir Singh

Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h

[Arnd Bergmann]

On Thu, Mar 15, 2018 at 3:51 AM, Deepa Dinamani  wrote:
> On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann  wrote:
>> On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani  
>> wrote:
>>> The file arch/arm64/kernel/process.c needs asm/compat.h also to be
>>> included directly since this is included conditionally from
>>> include/compat.h. This does seem to be typical of arm64 as I was not
>>> completely able to get rid of asm/compat.h includes for arm64 in this
>>> series. My plan is to have separate patches to get rid of asm/compat.h
>>> includes for the architectures that are not straight forward to keep
>>> this series simple.
>>> I will fix this and update the series.
>>>
>>
>> I ran across the same thing in two more files during randconfig testing on
>> arm64 now, adding this fixup on top for the moment, but maybe there
>> is a better way:
>
> I was looking at how Al tested his uaccess patches:
> https://www.spinics.net/lists/linux-fsdevel/msg108752.html
>
> He seems to be running the kbuild bot tests on his own git.
> Is it possible to verify it this way on the 2038 tree? Or, I could
> host a tree also.

The kbuild bot should generally pick up any branch on git.kernel.org,
and the patches sent to the mailing list. It tests a lot of things
configurations, but I tend to find some things that it doesn't find
by doing lots of randconfig builds on fewer target architectures
(I only build arm, arm64 and x86 regularly).

I remember that there was some discussion about a method
to get the bot to test other branches (besides asking Fengguang
to add it manually), but I don't remember what came out of that.

Arnd

Re: [PATCH kernel] powerpc/npu: Do not try invalidating 32bit table when 64bit table is enabled

[Alexey Kardashevskiy]

On 15/3/18 4:18 pm, Alistair Popple wrote:
> I must admit I haven't really looked at the iommu_table_group code in depth so
> don't fully understand it, but I was wondering why we don't hit this for 
> NVLink1
> as well?
> 
> The error that Skiboot is printing is because the requested page size doesn't
> match expected so I guess there is a possibility the address might not meet 
> the
> required alignment (I don't know we don't just check that directly).
> 
> The reason you don't see this on NVLink1 is that we rely on the kernel to do 
> the
> TCE invalidate directly rather than via an OPAL call, and the kernel seems to 
> do
> less checking.

Correct.

> So I wonder if there is a bug there as well (invalidate for a
> mismatched page size/address alignment)?
> And wether this would also fix that?

Correct. Although afair we simply reset the entire cache (due to some
hardware bug about which I am not now sure that it actually exists) so we
did not see it. May be with this fix applied we won't have to do that and
can invalidate individual tces (but I doubt because of the bug).




> 
> - Alistair
> 
> On Tuesday, 13 February 2018 4:51:35 PM AEDT Alexey Kardashevskiy wrote:
>> GPUs and the corresponding NVLink bridges get different PEs as they have
>> separate translation validation entries (TVEs). We put these PEs to
>> the same IOMMU group so they cannot be passed through separately.
>> So the iommu_table_group_ops::set_window/unset_window for GPUs do set
>> tables to the NPU PEs as well which means that iommu_table's list of
>> attached PEs (iommu_table_group_link) has both GPU and NPU PEs linked.
>> This list is used for TCE cache invalidation.
>>
>> The problem is that NPU PE has just a single TVE and can be programmed
>> to point to 32bit or 64bit windows while GPU PE has two (as any other PCI
>> device). So we end up having an 32bit iommu_table struct linked to both
>> PEs even though only the 64bit TCE table cache can be invalidated on NPU.
>> And a relatively recent skiboot detects this and prints errors.
>>
>> This changes GPU's iommu_table_group_ops::set_window/unset_window to make
>> sure that NPU PE is only linked to the table actually used by the hardware.
>> If there are two tables used by an IOMMU group, the NPU PE will use
>> the last programmed one which with the current use scenarios is expected
>> to be a 64bit one.
>>
>> Signed-off-by: Alexey Kardashevskiy 
>> ---
>>
>> Do we need BUG_ON(IOMMU_TABLE_GROUP_MAX_TABLES != 2)?
>>
>>
>> This is an example for:
>>
>> 0004:04:00.0 3D: NVIDIA Corporation Device 1db1 (rev a1)
>> 0006:00:00.0 Bridge: IBM Device 04ea (rev 01)
>> 0006:00:00.1 Bridge: IBM Device 04ea (rev 01)
>>
>> Before the patch (npu2_tce_kill messages are from skiboot):
>>
>> pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000
>> pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000
>> pci 0004:04 : [PE# 00] Setting up window#1 
>> 800..800 pg=1
>> pci 0006:00:00.0: [PE# 0d] Setting up window 
>> 800..800 pg=1
>> NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1)
>> NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1)
>> NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1)
>> NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1)
>> NPU6: npu2_tce_kill: Unexpected TCE size (got 0x1000 expected 0x1)
>> ...
>> pci 0004:04 : [PE# 00] Removing DMA window #0
>> pci 0006:00:00.0: [PE# 0d] Removing DMA window
>> pci 0004:04 : [PE# 00] Removing DMA window #1
>> pci 0006:00:00.0: [PE# 0d] Removing DMA window
>> pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000
>> pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000
>> pci 0004:04 : [PE# 00] Setting up window#1 
>> 800..800 pg=1
>> pci 0006:00:00.0: [PE# 0d] Setting up window 
>> 800..800 pg=1
>>
>> After the patch (no errors here):
>>
>> pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000
>> pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000
>> pci 0004:04 : [PE# 00] Setting up window#1 
>> 800..800 pg=1
>> pci 0006:00:00.0: [PE# 0d] Removing DMA window
>> pci 0006:00:00.0: [PE# 0d] Setting up window 
>> 800..800 pg=1
>> pci 0004:04 : [PE# 00] Removing DMA window #0
>> pci 0004:04 : [PE# 00] Removing DMA window #1
>> pci 0006:00:00.0: [PE# 0d] Removing DMA window
>> pci 0004:04 : [PE# 00] Setting up window#0 0..3fff pg=1000
>> pci 0006:00:00.0: [PE# 0d] Setting up window 0..3fff pg=1000
>> pci 0004:04 : [PE# 00] Setting up window#1 
>> 800..800 pg=1
>> pci 0006:00:00.0: [PE# 0d] Removing DMA window
>> pci 0006:00:00.0: [PE# 0d] Setting up window 
>> 800..800 pg=1
>> ---
>>  

[RFC PATCH] powerpc/fadump: Reservationless firmware assisted dump

[Mahesh J Salgaonkar]

From: Mahesh Salgaonkar 

One of the primary issues with Firmware Assisted Dump (fadump) on Power
is that it needs a large amount of memory to be reserved. On large
systems with TeraBytes of memory, this reservation can be quite
significant.

In some cases, fadump fails if the memory reserved is insufficient, or
if the reserved memory was DLPAR hot-removed.

In the normal case, post reboot, the preserved memory is filtered to
extract only relevant areas of interest using the makedumpfile tool.
While the tool provides flexibility to determine what needs to be part
of the dump and what memory to filter out, all supported distributions
default this to "Capture only kernel data and nothing else".

We take advantage of this default and the Linux kernel's Contiguous
Memory Allocator (CMA) to fundamentally change the memory reservation
model for fadump. Fadump can now only capture kernel memory.

Instead of setting aside a significant chunk of memory nobody can use,
this patch uses CMA instead, to reserve a significant chunk of memory
that the kernel is prevented from using (due to MIGRATE_CMA), but
applications are free to use it.

Essentially, on a P9 LPAR with 2 cores, 8GB RAM and current upstream:
[root@zzxx-yy10 ~]# free -m
  totalusedfree  shared  buff/cache   available
Mem:   7557 1936822  12 5416725
Swap:  4095   04095

With this patch:
[root@zzxx-yy10 ~]# free -m
  totalusedfree  shared  buff/cache   available
Mem:   8133 1947464  12 4757338
Swap:  4095   04095

Changes made here are completely transparent to how fadump has
traditionally worked.

An additional advantage is that this mechanism is immune to DLPAR memory
remove (since the CMA memory cannot be removed).

Thanks to Aneesh Kumar and Anshuman Khandual for helping us understand
CMA and its usage.

TODO:
- Handle case where CMA reservation spans nodes.

Signed-off-by: Ananth N Mavinakayanahalli 
Signed-off-by: Mahesh Salgaonkar 
---
 arch/powerpc/include/asm/fadump.h |3 +
 arch/powerpc/kernel/fadump.c  |  179 -
 2 files changed, 156 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h 
b/arch/powerpc/include/asm/fadump.h
index 5a23010af600..776cba0baec4 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -119,6 +119,7 @@ struct fadump_mem_struct {
struct fadump_section   cpu_state_data;
struct fadump_section   hpte_region;
struct fadump_section   rmr_region;
+   struct fadump_section   metadata_region;
 };
 
 /* Firmware-assisted dump configuration details. */
@@ -141,6 +142,8 @@ struct fw_dump {
unsigned long   fadump_supported:1;
unsigned long   dump_active:1;
unsigned long   dump_registered:1;
+   /* flag to indicate fadump metadata area is cma allocated */
+   unsigned long   cma_alloc:1;
 };
 
 /*
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 3c2c2688918f..5ca0cb1b6028 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -45,11 +46,59 @@
 static struct fw_dump fw_dump;
 static struct fadump_mem_struct fdm;
 static const struct fadump_mem_struct *fdm_active;
+static struct cma *fadump_cma;
 
 static DEFINE_MUTEX(fadump_mutex);
 struct fad_crash_memory_ranges crash_memory_ranges[INIT_CRASHMEM_RANGES];
 int crash_mem_ranges;
 
+/**
+ * fadump_cma_reserve() - reserve area for fadump memory reservation
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the memblock allocator
+ * has been activated.
+ */
+int __init fadump_cma_reserve(void)
+{
+   unsigned long long base, size;
+   int rc;
+
+   if (!fw_dump.fadump_enabled)
+   return 0;
+
+   base = fw_dump.reserve_dump_area_start;
+   size = fw_dump.reserve_dump_area_size;
+   pr_debug("Original reserve area base %ld, size %ld\n",
+   (unsigned long)base >> 20,
+   (unsigned long)size >> 20);
+   if (!size)
+   return 0;
+
+   printk("%s: reserving %ld MiB for firmware-assisted dump area\n"
+   , __func__, (unsigned long)size >> 20);
+   rc = cma_declare_contiguous(base, size, 0, 0, 0, false,
+   "fadump_cma", _cma);
+   if (rc) {
+   printk(KERN_ERR "fadump: Failed to reserve cma area for "
+   "firmware-assisted dump, %d\n", rc);
+   fw_dump.reserve_dump_area_size = 0;
+  

Re: [PATCH] cxl: Perform NULL check for 'cxl_afu *' at various places in cxl

[Vaibhav Jain]

Thanks for reviewing this patch Fred,

Frederic Barrat  writes:

> So we are calling functions with an invalid afu argument. We can verify 
> in the callees the value of the afu pointer, like you're doing here, but 
> why not tackle it at source and avoid calling the function in the first 
> place?
Couple of reasons:
* Having checks for NULL afu at the call sites rather than the functions
  being called will lead to these checks scattered at more than a few
  places in code. Many of these functions are called via indirect branch
  from cxl_backend_ops and have their call sites scattered in the
  code. Having this check in the called functions is a much smaller change
  in comparison.

* Some of these functions are called are called from outside CXL e.g
  cxl_dev_context_init(). So putting the NULL check at every caller site
  might not be possible.

* Some funtions need to handle AFU init failures in special way e.g like
  cxl_vphb_error_detected() need to force a card hotplug so that AFU
  reinit can be tried.

* None of these functions are in any hotpath in the code so having an
  extra check at the beginning of the code wont have a much performance
  impact.

-- 
Vaibhav Jain 
Linux Technology Center, IBM India Pvt. Ltd.