Re: [PATCH] powerpc/traps: Declare unrecoverable_exception() as __noreturn

2021-02-10 Thread Gabriel Paubert
On Thu, Feb 11, 2021 at 06:34:43AM +, Christophe Leroy wrote:
> unrecoverable_exception() is never expected to return, most callers
> have an infiniteloop in case it returns.
> 
> Ensure it really never returns by terminating it with a BUG(), and
> declare it __no_return.
> 
> It always GCC to really simplify functions calling it. In the exemple below,

s/always/allows ?

(Otherwise I can't parse it.)

> it avoids the stack frame in the likely fast path and avoids code duplication
> for the exit.

Indeed, nice code generation improvement.

> 
> With this patch:
> 
>   0348 :
>348:   81 43 00 84 lwz r10,132(r3)
>34c:   71 48 00 02 andi.   r8,r10,2
>350:   41 82 00 2c beq 37c 
>354:   71 4a 40 00 andi.   r10,r10,16384
>358:   40 82 00 20 bne 378 
>35c:   80 62 00 70 lwz r3,112(r2)
>360:   74 63 00 01 andis.  r3,r3,1
>364:   40 82 00 28 bne 38c 
>368:   7d 40 00 a6 mfmsr   r10
>36c:   7c 11 13 a6 mtspr   81,r0
>370:   7c 12 13 a6 mtspr   82,r0
>374:   4e 80 00 20 blr
>378:   48 00 00 00 b   378 

Infinite loop (seems to be on test of MSR_PR)?

Gabriel

>37c:   94 21 ff f0 stwur1,-16(r1)
>380:   7c 08 02 a6 mflrr0
>384:   90 01 00 14 stw r0,20(r1)
>388:   48 00 00 01 bl  388 
>   388: R_PPC_REL24unrecoverable_exception
>38c:   38 e2 00 70 addir7,r2,112
>390:   3d 00 00 01 lis r8,1
>394:   7c c0 38 28 lwarx   r6,0,r7
>398:   7c c6 40 78 andcr6,r6,r8
>39c:   7c c0 39 2d stwcx.  r6,0,r7
>3a0:   40 a2 ff f4 bne 394 
>3a4:   38 60 00 01 li  r3,1
>3a8:   4b ff ff c0 b   368 
> 
> Without this patch:
> 
>   0348 :
>348:   94 21 ff f0 stwur1,-16(r1)
>34c:   93 e1 00 0c stw r31,12(r1)
>350:   7c 7f 1b 78 mr  r31,r3
>354:   81 23 00 84 lwz r9,132(r3)
>358:   71 2a 00 02 andi.   r10,r9,2
>35c:   41 82 00 34 beq 390 
>360:   71 29 40 00 andi.   r9,r9,16384
>364:   40 82 00 28 bne 38c 
>368:   80 62 00 70 lwz r3,112(r2)
>36c:   74 63 00 01 andis.  r3,r3,1
>370:   40 82 00 3c bne 3ac 
>374:   7d 20 00 a6 mfmsr   r9
>378:   7c 11 13 a6 mtspr   81,r0
>37c:   7c 12 13 a6 mtspr   82,r0
>380:   83 e1 00 0c lwz r31,12(r1)
>384:   38 21 00 10 addir1,r1,16
>388:   4e 80 00 20 blr
>38c:   48 00 00 00 b   38c 
>390:   7c 08 02 a6 mflrr0
>394:   90 01 00 14 stw r0,20(r1)
>398:   48 00 00 01 bl  398 
>   398: R_PPC_REL24unrecoverable_exception
>39c:   80 01 00 14 lwz r0,20(r1)
>3a0:   81 3f 00 84 lwz r9,132(r31)
>3a4:   7c 08 03 a6 mtlrr0
>3a8:   4b ff ff b8 b   360 
>3ac:   39 02 00 70 addir8,r2,112
>3b0:   3d 40 00 01 lis r10,1
>3b4:   7c e0 40 28 lwarx   r7,0,r8
>3b8:   7c e7 50 78 andcr7,r7,r10
>3bc:   7c e0 41 2d stwcx.  r7,0,r8
>3c0:   40 a2 ff f4 bne 3b4 
>3c4:   38 60 00 01 li  r3,1
>3c8:   4b ff ff ac b   374 
> 
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/include/asm/interrupt.h | 2 +-
>  arch/powerpc/kernel/interrupt.c  | 1 -
>  arch/powerpc/kernel/traps.c  | 2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/interrupt.h 
> b/arch/powerpc/include/asm/interrupt.h
> index dcff30e3919b..fa8bfb91f8df 100644
> --- a/arch/powerpc/include/asm/interrupt.h
> +++ b/arch/powerpc/include/asm/interrupt.h
> @@ -411,7 +411,7 @@ DECLARE_INTERRUPT_HANDLER(altivec_assist_exception);
>  DECLARE_INTERRUPT_HANDLER(CacheLockingException);
>  DECLARE_INTERRUPT_HANDLER(SPEFloatingPointException);
>  DECLARE_INTERRUPT_HANDLER(SPEFloatingPointRoundException);
> -DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
> +DECLARE_INTERRUPT_HANDLER(unrecoverable_exception) __noreturn;
>  DECLARE_INTERRUPT_HANDLER(WatchdogException);
>  DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
>  
> diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
> index eca3be36c18c..7e7106641ca9 100644
> --- a/arch/powerpc/kernel/interrupt.c
> +++ b/arch/powerpc/kernel/interrupt.c
> @@ -440,7 +440,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
> pt_regs *regs, unsigned
>   return ret;
>  }
>  
> -void unrecoverable_exception(struct pt_regs *regs);
>  void preempt_schedule_irq(void);
>  
>  notrace unsigned long 

[PATCH] powerpc/bug: Remove specific powerpc BUG_ON()

2021-02-10 Thread Christophe Leroy
powerpc BUG_ON() is based on using twnei or tdnei instruction,
which obliges gcc to format the condition into a 0 or 1 value
in a register.

By using a generic implementation, gcc will generate a branch
to the unconditional trap generated by BUG().

As modern powerpc implement branch folding, that's even more efficient.

See below the difference at the entry of system_call_exception.

With the patch:

 :
   0:   81 6a 00 84 lwz r11,132(r10)
   4:   90 6a 00 88 stw r3,136(r10)
   8:   71 60 00 02 andi.   r0,r11,2
   c:   41 82 00 70 beq 7c 
  10:   71 60 40 00 andi.   r0,r11,16384
  14:   41 82 00 6c beq 80 
  18:   71 6b 80 00 andi.   r11,r11,32768
  1c:   41 82 00 68 beq 84 
  20:   94 21 ff e0 stwur1,-32(r1)
  24:   93 e1 00 1c stw r31,28(r1)
  28:   7d 8c 42 e6 mftbr12
...
  7c:   0f e0 00 00 twuir0,0
  80:   0f e0 00 00 twuir0,0
  84:   0f e0 00 00 twuir0,0

Without the patch:

 :
   0:   94 21 ff e0 stwur1,-32(r1)
   4:   93 e1 00 1c stw r31,28(r1)
   8:   90 6a 00 88 stw r3,136(r10)
   c:   81 6a 00 84 lwz r11,132(r10)
  10:   69 60 00 02 xorir0,r11,2
  14:   54 00 ff fe rlwinm  r0,r0,31,31,31
  18:   0f 00 00 00 twnei   r0,0
  1c:   69 60 40 00 xorir0,r11,16384
  20:   54 00 97 fe rlwinm  r0,r0,18,31,31
  24:   0f 00 00 00 twnei   r0,0
  28:   69 6b 80 00 xorir11,r11,32768
  2c:   55 6b 8f fe rlwinm  r11,r11,17,31,31
  30:   0f 0b 00 00 twnei   r11,0
  34:   7d 8c 42 e6 mftbr12

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/bug.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index d1635ffbb179..21103d3e1f29 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -69,15 +69,6 @@
unreachable();  \
 } while (0)
 
-#define BUG_ON(x) do { \
-   if (__builtin_constant_p(x)) {  \
-   if (x)  \
-   BUG();  \
-   } else {\
-   BUG_ENTRY(PPC_TLNEI " %4, 0", 0, "r" ((__force long)(x)));  
\
-   }   \
-} while (0)
-
 #define __WARN_FLAGS(flags) BUG_ENTRY("twi 31, 0, 0", BUGFLAG_WARNING | 
(flags))
 
 #define WARN_ON(x) ({  \
@@ -94,7 +85,6 @@
 })
 
 #define HAVE_ARCH_BUG
-#define HAVE_ARCH_BUG_ON
 #define HAVE_ARCH_WARN_ON
 #endif /* __ASSEMBLY __ */
 #else
-- 
2.25.0



[PATCH v2] powerpc/traps: Declare unrecoverable_exception() as __noreturn

2021-02-10 Thread Christophe Leroy
unrecoverable_exception() is never expected to return, most callers
have an infiniteloop in case it returns.

Ensure it really never returns by terminating it with a BUG(), and
declare it __no_return.

It always GCC to really simplify functions calling it. In the exemple below,
it avoids the stack frame in the likely fast path and avoids code duplication
for the exit.

With this patch:

0348 :
 348:   81 43 00 84 lwz r10,132(r3)
 34c:   71 48 00 02 andi.   r8,r10,2
 350:   41 82 00 2c beq 37c 
 354:   71 4a 40 00 andi.   r10,r10,16384
 358:   40 82 00 20 bne 378 
 35c:   80 62 00 70 lwz r3,112(r2)
 360:   74 63 00 01 andis.  r3,r3,1
 364:   40 82 00 28 bne 38c 
 368:   7d 40 00 a6 mfmsr   r10
 36c:   7c 11 13 a6 mtspr   81,r0
 370:   7c 12 13 a6 mtspr   82,r0
 374:   4e 80 00 20 blr
 378:   48 00 00 00 b   378 
 37c:   94 21 ff f0 stwur1,-16(r1)
 380:   7c 08 02 a6 mflrr0
 384:   90 01 00 14 stw r0,20(r1)
 388:   48 00 00 01 bl  388 
388: R_PPC_REL24unrecoverable_exception
 38c:   38 e2 00 70 addir7,r2,112
 390:   3d 00 00 01 lis r8,1
 394:   7c c0 38 28 lwarx   r6,0,r7
 398:   7c c6 40 78 andcr6,r6,r8
 39c:   7c c0 39 2d stwcx.  r6,0,r7
 3a0:   40 a2 ff f4 bne 394 
 3a4:   38 60 00 01 li  r3,1
 3a8:   4b ff ff c0 b   368 

Without this patch:

0348 :
 348:   94 21 ff f0 stwur1,-16(r1)
 34c:   93 e1 00 0c stw r31,12(r1)
 350:   7c 7f 1b 78 mr  r31,r3
 354:   81 23 00 84 lwz r9,132(r3)
 358:   71 2a 00 02 andi.   r10,r9,2
 35c:   41 82 00 34 beq 390 
 360:   71 29 40 00 andi.   r9,r9,16384
 364:   40 82 00 28 bne 38c 
 368:   80 62 00 70 lwz r3,112(r2)
 36c:   74 63 00 01 andis.  r3,r3,1
 370:   40 82 00 3c bne 3ac 
 374:   7d 20 00 a6 mfmsr   r9
 378:   7c 11 13 a6 mtspr   81,r0
 37c:   7c 12 13 a6 mtspr   82,r0
 380:   83 e1 00 0c lwz r31,12(r1)
 384:   38 21 00 10 addir1,r1,16
 388:   4e 80 00 20 blr
 38c:   48 00 00 00 b   38c 
 390:   7c 08 02 a6 mflrr0
 394:   90 01 00 14 stw r0,20(r1)
 398:   48 00 00 01 bl  398 
398: R_PPC_REL24unrecoverable_exception
 39c:   80 01 00 14 lwz r0,20(r1)
 3a0:   81 3f 00 84 lwz r9,132(r31)
 3a4:   7c 08 03 a6 mtlrr0
 3a8:   4b ff ff b8 b   360 
 3ac:   39 02 00 70 addir8,r2,112
 3b0:   3d 40 00 01 lis r10,1
 3b4:   7c e0 40 28 lwarx   r7,0,r8
 3b8:   7c e7 50 78 andcr7,r7,r10
 3bc:   7c e0 41 2d stwcx.  r7,0,r8
 3c0:   40 a2 ff f4 bne 3b4 
 3c4:   38 60 00 01 li  r3,1
 3c8:   4b ff ff ac b   374 

Signed-off-by: Christophe Leroy 
---
v2: Also add __noreturn to the definition
---
 arch/powerpc/include/asm/interrupt.h | 2 +-
 arch/powerpc/kernel/interrupt.c  | 1 -
 arch/powerpc/kernel/traps.c  | 4 +++-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index dcff30e3919b..e6950352347d 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -411,7 +411,7 @@ DECLARE_INTERRUPT_HANDLER(altivec_assist_exception);
 DECLARE_INTERRUPT_HANDLER(CacheLockingException);
 DECLARE_INTERRUPT_HANDLER(SPEFloatingPointException);
 DECLARE_INTERRUPT_HANDLER(SPEFloatingPointRoundException);
-DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
+__noreturn DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
 DECLARE_INTERRUPT_HANDLER(WatchdogException);
 DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
 
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index eca3be36c18c..7e7106641ca9 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -440,7 +440,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
return ret;
 }
 
-void unrecoverable_exception(struct pt_regs *regs);
 void preempt_schedule_irq(void);
 
 notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, 
unsigned long msr)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2afa05ad21c8..22486d27fa82 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2168,11 +2168,13 @@ 

Re: [PATCH] powerpc/traps: Declare unrecoverable_exception() as __noreturn

2021-02-10 Thread Christophe Leroy




Le 11/02/2021 à 07:34, Christophe Leroy a écrit :

unrecoverable_exception() is never expected to return, most callers
have an infiniteloop in case it returns.

Ensure it really never returns by terminating it with a BUG(), and
declare it __no_return.


Not so easy, gcc complains about DEFINE_INTERRUPT_HANDLER() returning while the function is declared 
__noreturn, __noreturn is needed there too.




It always GCC to really simplify functions calling it. In the exemple below,
it avoids the stack frame in the likely fast path and avoids code duplication
for the exit.

With this patch:

0348 :
 348:   81 43 00 84 lwz r10,132(r3)
 34c:   71 48 00 02 andi.   r8,r10,2
 350:   41 82 00 2c beq 37c 
 354:   71 4a 40 00 andi.   r10,r10,16384
 358:   40 82 00 20 bne 378 
 35c:   80 62 00 70 lwz r3,112(r2)
 360:   74 63 00 01 andis.  r3,r3,1
 364:   40 82 00 28 bne 38c 
 368:   7d 40 00 a6 mfmsr   r10
 36c:   7c 11 13 a6 mtspr   81,r0
 370:   7c 12 13 a6 mtspr   82,r0
 374:   4e 80 00 20 blr
 378:   48 00 00 00 b   378 
 37c:   94 21 ff f0 stwur1,-16(r1)
 380:   7c 08 02 a6 mflrr0
 384:   90 01 00 14 stw r0,20(r1)
 388:   48 00 00 01 bl  388 
388: R_PPC_REL24unrecoverable_exception
 38c:   38 e2 00 70 addir7,r2,112
 390:   3d 00 00 01 lis r8,1
 394:   7c c0 38 28 lwarx   r6,0,r7
 398:   7c c6 40 78 andcr6,r6,r8
 39c:   7c c0 39 2d stwcx.  r6,0,r7
 3a0:   40 a2 ff f4 bne 394 
 3a4:   38 60 00 01 li  r3,1
 3a8:   4b ff ff c0 b   368 

Without this patch:

0348 :
 348:   94 21 ff f0 stwur1,-16(r1)
 34c:   93 e1 00 0c stw r31,12(r1)
 350:   7c 7f 1b 78 mr  r31,r3
 354:   81 23 00 84 lwz r9,132(r3)
 358:   71 2a 00 02 andi.   r10,r9,2
 35c:   41 82 00 34 beq 390 
 360:   71 29 40 00 andi.   r9,r9,16384
 364:   40 82 00 28 bne 38c 
 368:   80 62 00 70 lwz r3,112(r2)
 36c:   74 63 00 01 andis.  r3,r3,1
 370:   40 82 00 3c bne 3ac 
 374:   7d 20 00 a6 mfmsr   r9
 378:   7c 11 13 a6 mtspr   81,r0
 37c:   7c 12 13 a6 mtspr   82,r0
 380:   83 e1 00 0c lwz r31,12(r1)
 384:   38 21 00 10 addir1,r1,16
 388:   4e 80 00 20 blr
 38c:   48 00 00 00 b   38c 
 390:   7c 08 02 a6 mflrr0
 394:   90 01 00 14 stw r0,20(r1)
 398:   48 00 00 01 bl  398 
398: R_PPC_REL24unrecoverable_exception
 39c:   80 01 00 14 lwz r0,20(r1)
 3a0:   81 3f 00 84 lwz r9,132(r31)
 3a4:   7c 08 03 a6 mtlrr0
 3a8:   4b ff ff b8 b   360 
 3ac:   39 02 00 70 addir8,r2,112
 3b0:   3d 40 00 01 lis r10,1
 3b4:   7c e0 40 28 lwarx   r7,0,r8
 3b8:   7c e7 50 78 andcr7,r7,r10
 3bc:   7c e0 41 2d stwcx.  r7,0,r8
 3c0:   40 a2 ff f4 bne 3b4 
 3c4:   38 60 00 01 li  r3,1
 3c8:   4b ff ff ac b   374 

Signed-off-by: Christophe Leroy 
---
  arch/powerpc/include/asm/interrupt.h | 2 +-
  arch/powerpc/kernel/interrupt.c  | 1 -
  arch/powerpc/kernel/traps.c  | 2 ++
  3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index dcff30e3919b..fa8bfb91f8df 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -411,7 +411,7 @@ DECLARE_INTERRUPT_HANDLER(altivec_assist_exception);
  DECLARE_INTERRUPT_HANDLER(CacheLockingException);
  DECLARE_INTERRUPT_HANDLER(SPEFloatingPointException);
  DECLARE_INTERRUPT_HANDLER(SPEFloatingPointRoundException);
-DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
+DECLARE_INTERRUPT_HANDLER(unrecoverable_exception) __noreturn;
  DECLARE_INTERRUPT_HANDLER(WatchdogException);
  DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
  
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c

index eca3be36c18c..7e7106641ca9 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -440,7 +440,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
return ret;
  }
  
-void unrecoverable_exception(struct pt_regs *regs);

  void preempt_schedule_irq(void);
  
  notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, unsigned long msr)

diff --git a/arch/powerpc/kernel/traps.c 

[PATCH] powerpc: remove interrupt handler functions from the noinstr section

2021-02-10 Thread Nicholas Piggin
The allyesconfig ppc64 kernel fails to link with relocations unable to
fit after commit 3a96570ffceb ("powerpc: convert interrupt handlers to
use wrappers"), which is due to the interrupt handler functions being
put into the .noinstr.text section, which the linker script places on
the opposite side of the main .text section from the interrupt entry
asm code which calls the handlers.

This results in a lot of linker stubs that overwhelm the 252-byte sized
space we allow for them, or in the case of BE a .opd relocation link
error for some reason.

It's not required to put interrupt handlers in the .noinstr section,
previously they used NOKPROBE_SYMBOL, so take them out and replace
with a NOKPROBE_SYMBOL in the wrapper macro. Remove the explicit
NOKPROBE_SYMBOL macros in the interrupt handler functions. This makes
a number of interrupt handlers nokprobe that were not prior to the
interrupt wrappers commit, but since that commit they were made
nokprobe due to being in .noinstr.text, so this fix does not change
that.

The fixes tag is different to the commit that first exposes the problem
because it is where the wrapper macros were introduced.

Fixes: 8d41fc618ab8 ("powerpc: interrupt handler wrapper functions")
Reported-by: Stephen Rothwell 
Signed-off-by: Nicholas Piggin 
---
 arch/powerpc/include/asm/interrupt.h | 25 -
 arch/powerpc/kernel/traps.c  |  9 -
 arch/powerpc/mm/fault.c  |  1 -
 3 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index 4badb3e51c19..ffb568587553 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct interrupt_state {
@@ -164,6 +165,15 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #endif
 }
 
+/*
+ * Don't use like to use noinstr here like x86, but rather add NOKPROBE_SYMBOL
+ * to each function definition. The reason for this is the noinstr section
+ * is placed after the main text section, i.e., very far away from the
+ * interrupt entry asm. That creates problems with fitting linker stubs when
+ * building large kernels.
+ */
+#define interrupt_handler __visible noinline notrace __no_kcsan 
__no_sanitize_address
+
 /**
  * DECLARE_INTERRUPT_HANDLER_RAW - Declare raw interrupt handler function
  * @func:  Function name of the entry point
@@ -198,7 +208,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DEFINE_INTERRUPT_HANDLER_RAW(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+interrupt_handler long func(struct pt_regs *regs)  \
 {  \
long ret;   \
\
@@ -206,6 +216,7 @@ __visible noinstr long func(struct pt_regs *regs)   
\
\
return ret; \
 }  \
+NOKPROBE_SYMBOL(func); \
\
 static __always_inline long ##func(struct pt_regs *regs)
 
@@ -228,7 +239,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER(func) \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+interrupt_handler void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -238,6 +249,7 @@ __visible noinstr void func(struct pt_regs *regs)   
\
\
interrupt_exit_prepare(regs, );   \
 }  \
+NOKPROBE_SYMBOL(func); \
\
 static __always_inline void ##func(struct pt_regs *regs)
 
@@ -262,7 +274,7 @@ static __always_inline void ##func(struct pt_regs *regs)

[PATCH] powerpc/traps: Declare unrecoverable_exception() as __noreturn

2021-02-10 Thread Christophe Leroy
unrecoverable_exception() is never expected to return, most callers
have an infiniteloop in case it returns.

Ensure it really never returns by terminating it with a BUG(), and
declare it __no_return.

It always GCC to really simplify functions calling it. In the exemple below,
it avoids the stack frame in the likely fast path and avoids code duplication
for the exit.

With this patch:

0348 :
 348:   81 43 00 84 lwz r10,132(r3)
 34c:   71 48 00 02 andi.   r8,r10,2
 350:   41 82 00 2c beq 37c 
 354:   71 4a 40 00 andi.   r10,r10,16384
 358:   40 82 00 20 bne 378 
 35c:   80 62 00 70 lwz r3,112(r2)
 360:   74 63 00 01 andis.  r3,r3,1
 364:   40 82 00 28 bne 38c 
 368:   7d 40 00 a6 mfmsr   r10
 36c:   7c 11 13 a6 mtspr   81,r0
 370:   7c 12 13 a6 mtspr   82,r0
 374:   4e 80 00 20 blr
 378:   48 00 00 00 b   378 
 37c:   94 21 ff f0 stwur1,-16(r1)
 380:   7c 08 02 a6 mflrr0
 384:   90 01 00 14 stw r0,20(r1)
 388:   48 00 00 01 bl  388 
388: R_PPC_REL24unrecoverable_exception
 38c:   38 e2 00 70 addir7,r2,112
 390:   3d 00 00 01 lis r8,1
 394:   7c c0 38 28 lwarx   r6,0,r7
 398:   7c c6 40 78 andcr6,r6,r8
 39c:   7c c0 39 2d stwcx.  r6,0,r7
 3a0:   40 a2 ff f4 bne 394 
 3a4:   38 60 00 01 li  r3,1
 3a8:   4b ff ff c0 b   368 

Without this patch:

0348 :
 348:   94 21 ff f0 stwur1,-16(r1)
 34c:   93 e1 00 0c stw r31,12(r1)
 350:   7c 7f 1b 78 mr  r31,r3
 354:   81 23 00 84 lwz r9,132(r3)
 358:   71 2a 00 02 andi.   r10,r9,2
 35c:   41 82 00 34 beq 390 
 360:   71 29 40 00 andi.   r9,r9,16384
 364:   40 82 00 28 bne 38c 
 368:   80 62 00 70 lwz r3,112(r2)
 36c:   74 63 00 01 andis.  r3,r3,1
 370:   40 82 00 3c bne 3ac 
 374:   7d 20 00 a6 mfmsr   r9
 378:   7c 11 13 a6 mtspr   81,r0
 37c:   7c 12 13 a6 mtspr   82,r0
 380:   83 e1 00 0c lwz r31,12(r1)
 384:   38 21 00 10 addir1,r1,16
 388:   4e 80 00 20 blr
 38c:   48 00 00 00 b   38c 
 390:   7c 08 02 a6 mflrr0
 394:   90 01 00 14 stw r0,20(r1)
 398:   48 00 00 01 bl  398 
398: R_PPC_REL24unrecoverable_exception
 39c:   80 01 00 14 lwz r0,20(r1)
 3a0:   81 3f 00 84 lwz r9,132(r31)
 3a4:   7c 08 03 a6 mtlrr0
 3a8:   4b ff ff b8 b   360 
 3ac:   39 02 00 70 addir8,r2,112
 3b0:   3d 40 00 01 lis r10,1
 3b4:   7c e0 40 28 lwarx   r7,0,r8
 3b8:   7c e7 50 78 andcr7,r7,r10
 3bc:   7c e0 41 2d stwcx.  r7,0,r8
 3c0:   40 a2 ff f4 bne 3b4 
 3c4:   38 60 00 01 li  r3,1
 3c8:   4b ff ff ac b   374 

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/interrupt.h | 2 +-
 arch/powerpc/kernel/interrupt.c  | 1 -
 arch/powerpc/kernel/traps.c  | 2 ++
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index dcff30e3919b..fa8bfb91f8df 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -411,7 +411,7 @@ DECLARE_INTERRUPT_HANDLER(altivec_assist_exception);
 DECLARE_INTERRUPT_HANDLER(CacheLockingException);
 DECLARE_INTERRUPT_HANDLER(SPEFloatingPointException);
 DECLARE_INTERRUPT_HANDLER(SPEFloatingPointRoundException);
-DECLARE_INTERRUPT_HANDLER(unrecoverable_exception);
+DECLARE_INTERRUPT_HANDLER(unrecoverable_exception) __noreturn;
 DECLARE_INTERRUPT_HANDLER(WatchdogException);
 DECLARE_INTERRUPT_HANDLER(kernel_bad_stack);
 
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index eca3be36c18c..7e7106641ca9 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -440,7 +440,6 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
return ret;
 }
 
-void unrecoverable_exception(struct pt_regs *regs);
 void preempt_schedule_irq(void);
 
 notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, 
unsigned long msr)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2afa05ad21c8..1ff776e9e8e3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -2173,6 +2173,8 @@ DEFINE_INTERRUPT_HANDLER(unrecoverable_exception)

Re: Declaring unrecoverable_exception() as __noreturn ?

2021-02-10 Thread Christophe Leroy




Le 11/02/2021 à 05:41, Michael Ellerman a écrit :

Nicholas Piggin  writes:

Excerpts from Christophe Leroy's message of February 11, 2021 2:44 am:

As far as I can see, almost all callers of unrecoverable_exception() expect it 
to never return.

Can we mark it __noreturn ?


I don't see why not, do_exit is noreturn. We could make die() noreturn
as well.


I'm always nervous about that, because we can return if a debugger is
involved:

DEFINE_INTERRUPT_HANDLER(unrecoverable_exception)


Hum ... Is that correct to define it as an interrupt handler ?

Also, I see it declared a second time in interrupt.c, this time not as an interrupt handler. Is that 
wanted ?



{
pr_emerg("Unrecoverable exception %lx at %lx (msr=%lx)\n",
 regs->trap, regs->nip, regs->msr);
die("Unrecoverable exception", regs, SIGABRT);
}

void die(const char *str, struct pt_regs *regs, long err)
{
unsigned long flags;

/*
 * system_reset_excption handles debugger, crash dump, panic, for 0x100
 */
if (TRAP(regs) != 0x100) {
if (debugger(regs))
return;


We obviously don't want to optimise for that case, but it worries me
slightly if we're marking things noreturn when they can actually return.



I don't think I want to declare die() as __noreturn, need to look at it more in 
details first.

Christophe


Re: [PATCH v17 10/10] arm64: Enable passing IMA log to next kernel on kexec

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> Update CONFIG_KEXEC_FILE to select CONFIG_HAVE_IMA_KEXEC, if CONFIG_IMA
> is enabled, to indicate that the IMA measurement log information is
> present in the device tree for ARM64.
>
> Co-developed-by: Prakhar Srivastava 
> Signed-off-by: Prakhar Srivastava 
> Signed-off-by: Lakshmi Ramasubramanian 
> Suggested-by: Thiago Jung Bauermann 
> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v17 09/10] powerpc: Delete unused function delete_fdt_mem_rsv()

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> delete_fdt_mem_rsv() defined in "arch/powerpc/kexec/file_load.c"
> has been renamed to fdt_find_and_del_mem_rsv(), and moved to
> "drivers/of/kexec.c".
>
> Remove delete_fdt_mem_rsv() in "arch/powerpc/kexec/file_load.c".
>
> Co-developed-by: Prakhar Srivastava 
> Signed-off-by: Prakhar Srivastava 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/powerpc/include/asm/kexec.h |  1 -
>  arch/powerpc/kexec/file_load.c   | 32 
>  2 files changed, 33 deletions(-)

Reviewed-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v17 07/10] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> The functions defined in "arch/powerpc/kexec/ima.c" handle setting up
> and freeing the resources required to carry over the IMA measurement
> list from the current kernel to the next kernel across kexec system call.
> These functions do not have architecture specific code, but are
> currently limited to powerpc.
>
> Move remove_ima_buffer() and setup_ima_buffer() calls into
> of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Move the remaining architecture independent functions from
> "arch/powerpc/kexec/ima.c" to "drivers/of/kexec.c".
> Delete "arch/powerpc/kexec/ima.c" and "arch/powerpc/include/asm/ima.h".
> Remove references to the deleted files and functions in powerpc and
> in ima.
>
> Co-developed-by: Prakhar Srivastava 
> Signed-off-by: Prakhar Srivastava 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/powerpc/include/asm/ima.h|  27 
>  arch/powerpc/include/asm/kexec.h  |   3 -
>  arch/powerpc/kexec/Makefile   |   7 -
>  arch/powerpc/kexec/file_load.c|  25 
>  arch/powerpc/kexec/file_load_64.c |   4 -
>  arch/powerpc/kexec/ima.c  | 202 -
>  drivers/of/kexec.c| 239 ++
>  include/linux/of.h|   2 +
>  security/integrity/ima/ima.h  |   4 -
>  9 files changed, 241 insertions(+), 272 deletions(-)
>  delete mode 100644 arch/powerpc/include/asm/ima.h
>  delete mode 100644 arch/powerpc/kexec/ima.c

Reviewed-by: Thiago Jung Bauermann 
Tested-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: Declaring unrecoverable_exception() as __noreturn ?

2021-02-10 Thread Michael Ellerman
Nicholas Piggin  writes:
> Excerpts from Christophe Leroy's message of February 11, 2021 2:44 am:
>> As far as I can see, almost all callers of unrecoverable_exception() expect 
>> it to never return.
>> 
>> Can we mark it __noreturn ?
>
> I don't see why not, do_exit is noreturn. We could make die() noreturn 
> as well.

I'm always nervous about that, because we can return if a debugger is
involved:

DEFINE_INTERRUPT_HANDLER(unrecoverable_exception)
{
pr_emerg("Unrecoverable exception %lx at %lx (msr=%lx)\n",
 regs->trap, regs->nip, regs->msr);
die("Unrecoverable exception", regs, SIGABRT);
}

void die(const char *str, struct pt_regs *regs, long err)
{
unsigned long flags;

/*
 * system_reset_excption handles debugger, crash dump, panic, for 0x100
 */
if (TRAP(regs) != 0x100) {
if (debugger(regs))
return;


We obviously don't want to optimise for that case, but it worries me
slightly if we're marking things noreturn when they can actually return.

cheers


[powerpc:next-test] BUILD SUCCESS ea721ec55c8a4a166373978b9c8ce77374d684d6

2021-02-10 Thread kernel test robot
 at91_dt_defconfig
ia64 bigsur_defconfig
arm  integrator_defconfig
sh   se7750_defconfig
shsh7763rdp_defconfig
m68k   m5275evb_defconfig
sparc64  alldefconfig
powerpc mpc836x_mds_defconfig
nios2alldefconfig
mips   ip27_defconfig
powerpc  katmai_defconfig
xtensa   common_defconfig
riscvalldefconfig
armvexpress_defconfig
m68kmac_defconfig
arm pxa_defconfig
powerpc mpc832x_rdb_defconfig
sh   se7751_defconfig
ia64  gensparse_defconfig
m68k alldefconfig
m68k apollo_defconfig
m68k   bvme6000_defconfig
mips   ci20_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
parisc  defconfig
s390 allyesconfig
s390 allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
x86_64   randconfig-a006-20210209
x86_64   randconfig-a001-20210209
x86_64   randconfig-a005-20210209
x86_64   randconfig-a004-20210209
x86_64   randconfig-a002-20210209
x86_64   randconfig-a003-20210209
i386 randconfig-a001-20210209
i386 randconfig-a005-20210209
i386 randconfig-a003-20210209
i386 randconfig-a002-20210209
i386 randconfig-a006-20210209
i386 randconfig-a004-20210209
i386 randconfig-a016-20210209
i386 randconfig-a013-20210209
i386 randconfig-a012-20210209
i386 randconfig-a014-20210209
i386 randconfig-a011-20210209
i386 randconfig-a015-20210209
i386 randconfig-a016-20210210
i386 randconfig-a014-20210210
i386 randconfig-a012-20210210
i386 randconfig-a013-20210210
i386 randconfig-a011-20210210
i386 randconfig-a015-20210210
riscvnommu_k210_defconfig
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

clang tested configs:
x86_64   randconfig-a013-20210209
x86_64   randconfig-a014-20210209
x86_64   randconfig-a015-20210209
x86_64   randconfig-a012-20210209
x86_64   randconfig-a016-20210209
x86_64   randconfig-a011-20210209

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


Re: [PATCH v17 06/10] powerpc: Enable passing IMA log to next kernel on kexec

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> CONFIG_HAVE_IMA_KEXEC is enabled to indicate that the IMA measurement
> log information is present in the device tree. This should be selected
> only if CONFIG_IMA is enabled.
>
> Update CONFIG_KEXEC_FILE to select CONFIG_HAVE_IMA_KEXEC, if CONFIG_IMA
> is enabled, to indicate that the IMA measurement log information is
> present in the device tree for powerpc.
>
> Signed-off-by: Lakshmi Ramasubramanian 
> Suggested-by: Thiago Jung Bauermann 
> ---
>  arch/powerpc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v17 04/10] powerpc: Use common of_kexec_alloc_and_setup_fdt()

2021-02-10 Thread Lakshmi Ramasubramanian

On 2/10/21 5:42 PM, Thiago Jung Bauermann wrote:


Lakshmi Ramasubramanian  writes:


From: Rob Herring 

The code for setting up the /chosen node in the device tree
and updating the memory reservation for the next kernel has been
moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".

Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
and update the memory reservation for kexec for powerpc.

Signed-off-by: Rob Herring 
Signed-off-by: Lakshmi Ramasubramanian 
---
  arch/powerpc/include/asm/kexec.h  |   1 +
  arch/powerpc/kexec/elf_64.c   |  29 ---
  arch/powerpc/kexec/file_load.c| 132 +-
  arch/powerpc/kexec/file_load_64.c |   3 +
  4 files changed, 25 insertions(+), 140 deletions(-)

diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index dbf09d2f36d0..bdd0ddb9ac4d 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -111,6 +111,7 @@ struct kimage_arch {
unsigned long elf_headers_mem;
unsigned long elf_headers_sz;
void *elf_headers;
+   void *fdt;
  
  #ifdef CONFIG_IMA_KEXEC

phys_addr_t ima_buffer_addr;
diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index d0e459bb2f05..bfabd06f99b1 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -29,7 +30,6 @@ static void *elf64_load(struct kimage *image, char 
*kernel_buf,
unsigned long cmdline_len)
  {
int ret;
-   unsigned int fdt_size;
unsigned long kernel_load_addr;
unsigned long initrd_load_addr = 0, fdt_load_addr;
void *fdt;
@@ -102,19 +102,13 @@ static void *elf64_load(struct kimage *image, char 
*kernel_buf,
pr_debug("Loaded initrd at 0x%lx\n", initrd_load_addr);
}
  
-	fdt_size = fdt_totalsize(initial_boot_params) * 2;

-   fdt = kmalloc(fdt_size, GFP_KERNEL);
+   fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
+  initrd_len, cmdline);
if (!fdt) {
pr_err("Not enough memory for the device tree.\n");


This error string can be a bit misleading now, since
of_kexec_alloc_and_setup_fdt() can fail for reasons other than lack of
memory. I suggest changing it to the error string from fdt_open_into()
below:

pr_err("Error setting up the new device tree.\n");

With this change:

Agreed - I will make this change.



Reviewed-by: Thiago Jung Bauermann 

And also:

Tested-by: Thiago Jung Bauermann 



Thanks a lot for your help Thiago.

 -lakshmi



Re: [PATCH v17 04/10] powerpc: Use common of_kexec_alloc_and_setup_fdt()

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> From: Rob Herring 
>
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for powerpc.
>
> Signed-off-by: Rob Herring 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/powerpc/include/asm/kexec.h  |   1 +
>  arch/powerpc/kexec/elf_64.c   |  29 ---
>  arch/powerpc/kexec/file_load.c| 132 +-
>  arch/powerpc/kexec/file_load_64.c |   3 +
>  4 files changed, 25 insertions(+), 140 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/kexec.h 
> b/arch/powerpc/include/asm/kexec.h
> index dbf09d2f36d0..bdd0ddb9ac4d 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -111,6 +111,7 @@ struct kimage_arch {
>   unsigned long elf_headers_mem;
>   unsigned long elf_headers_sz;
>   void *elf_headers;
> + void *fdt;
>  
>  #ifdef CONFIG_IMA_KEXEC
>   phys_addr_t ima_buffer_addr;
> diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
> index d0e459bb2f05..bfabd06f99b1 100644
> --- a/arch/powerpc/kexec/elf_64.c
> +++ b/arch/powerpc/kexec/elf_64.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,7 +30,6 @@ static void *elf64_load(struct kimage *image, char 
> *kernel_buf,
>   unsigned long cmdline_len)
>  {
>   int ret;
> - unsigned int fdt_size;
>   unsigned long kernel_load_addr;
>   unsigned long initrd_load_addr = 0, fdt_load_addr;
>   void *fdt;
> @@ -102,19 +102,13 @@ static void *elf64_load(struct kimage *image, char 
> *kernel_buf,
>   pr_debug("Loaded initrd at 0x%lx\n", initrd_load_addr);
>   }
>  
> - fdt_size = fdt_totalsize(initial_boot_params) * 2;
> - fdt = kmalloc(fdt_size, GFP_KERNEL);
> + fdt = of_kexec_alloc_and_setup_fdt(image, initrd_load_addr,
> +initrd_len, cmdline);
>   if (!fdt) {
>   pr_err("Not enough memory for the device tree.\n");

This error string can be a bit misleading now, since
of_kexec_alloc_and_setup_fdt() can fail for reasons other than lack of
memory. I suggest changing it to the error string from fdt_open_into()
below:

pr_err("Error setting up the new device tree.\n");

With this change:

Reviewed-by: Thiago Jung Bauermann 

And also:

Tested-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v5 03/10] powerpc/signal64: Move non-inline functions out of setup_sigcontext()

2021-02-10 Thread Christopher M. Riedl
On Wed Feb 10, 2021 at 3:06 PM CST, Daniel Axtens wrote:
> "Christopher M. Riedl"  writes:
>
> > On Sun Feb 7, 2021 at 10:44 PM CST, Daniel Axtens wrote:
> >> Hi Chris,
> >>
> >> These two paragraphs are a little confusing and they seem slightly
> >> repetitive. But I get the general idea. Two specific comments below:
> >
> > Umm... yeah only one of those was supposed to be sent. I will reword
> > this for the next spin and address the comment below about how it is
> > not entirely clear that the inline functions are being moved out.
> >
> >>
> >> > There are non-inline functions which get called in setup_sigcontext() to
> >> > save register state to the thread struct. Move these functions into a
> >> > separate prepare_setup_sigcontext() function so that
> >> > setup_sigcontext() can be refactored later into an "unsafe" version
> >> > which assumes an open uaccess window. Non-inline functions should be
> >> > avoided when uaccess is open.
> >>
> >> Why do we want to avoid non-inline functions? We came up with:
> >>
> >> - we want KUAP protection for as much of the kernel as possible: each
> >> extra bit of code run with the window open is another piece of attack
> >> surface.
> >>
> >> - non-inline functions default to traceable, which means we could end
> >> up ftracing while uaccess is enabled. That's a pretty big hole in the
> >> defences that KUAP provides.
> >>
> >> I think we've also had problems with the window being opened or closed
> >> unexpectedly by various bits of code? So the less code runs in uaccess
> >> context the less likely that is to occur.
> >
> > That is my understanding as well.
> >
> >>  
> >> > The majority of setup_sigcontext() can be refactored to execute in an
> >> > "unsafe" context (uaccess window is opened) except for some non-inline
> >> > functions. Move these out into a separate prepare_setup_sigcontext()
> >> > function which must be called first and before opening up a uaccess
> >> > window. A follow-up commit converts setup_sigcontext() to be "unsafe".
> >>
> >> This was a bit confusing until we realise that you're moving the _calls_
> >> to the non-inline functions out, not the non-inline functions
> >> themselves.
> >>
> >> > Signed-off-by: Christopher M. Riedl 
> >> > ---
> >> >  arch/powerpc/kernel/signal_64.c | 32 +---
> >> >  1 file changed, 21 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/arch/powerpc/kernel/signal_64.c 
> >> > b/arch/powerpc/kernel/signal_64.c
> >> > index f9e4a1ac440f..b211a8ea4f6e 100644
> >> > --- a/arch/powerpc/kernel/signal_64.c
> >> > +++ b/arch/powerpc/kernel/signal_64.c
> >> > @@ -79,6 +79,24 @@ static elf_vrreg_t __user *sigcontext_vmx_regs(struct 
> >> > sigcontext __user *sc)
> >> >  }
> >> >  #endif
> >> >  
> >> > +static void prepare_setup_sigcontext(struct task_struct *tsk, int 
> >> > ctx_has_vsx_region)
> >>
> >> ctx_has_vsx_region should probably be a bool? Although setup_sigcontext
> >> also has it as an int so I guess that's arguable, and maybe it's better
> >> to stick with this for constency.
> >
> > I've been told not to introduce unrelated changes in my patches before
> > so chose to keep this as an int for consistency.
>
> Seems reasonable.
>
> >
> >>
> >> > +{
> >> > +#ifdef CONFIG_ALTIVEC
> >> > +/* save altivec registers */
> >> > +if (tsk->thread.used_vr)
> >> > +flush_altivec_to_thread(tsk);
> >> > +if (cpu_has_feature(CPU_FTR_ALTIVEC))
> >> > +tsk->thread.vrsave = mfspr(SPRN_VRSAVE);
> >> > +#endif /* CONFIG_ALTIVEC */
> >> > +
> >> > +flush_fp_to_thread(tsk);
> >> > +
> >> > +#ifdef CONFIG_VSX
> >> > +if (tsk->thread.used_vsr && ctx_has_vsx_region)
> >> > +flush_vsx_to_thread(tsk);
> >> > +#endif /* CONFIG_VSX */
> >>
> >> Alternatively, given that this is the only use of ctx_has_vsx_region,
> >> mpe suggested that perhaps we could drop it entirely and always
> >> flush_vsx if used_vsr. The function is only ever called with either
> >> `current` or wth ctx_has_vsx_region set to 1, so in either case I think
> >> that's safe? I'm not sure if it would have performance implications.
> >
> > I think that could work as long as we can guarantee that the context
> > passed to swapcontext will always be sufficiently sized if used_vsr,
> > which I think *has* to be the case?
>
> I think you're always guaranteed that you'll have a big enough one
> in your kernel thread, which is what you end up writing to, iiuc?

Ah yup you are correct. I confused myself with the comment in
swapcontext about the ctx_size. We call prepare_setup_sigcontext() with
current which will always have space. The ctx_size only matters on the
next call to setup_sigcontext() which ends up potentially copying the
VSX region to userspace (v_regs).

TL;DR - yes, I'll remove the ctx_has_vsx_region argument to
prepare_setup_sigcontext() with the next version. Thanks!

>
> >>
> >> Should we move this and the altivec ifdef to 

Re: Declaring unrecoverable_exception() as __noreturn ?

2021-02-10 Thread Nicholas Piggin
Excerpts from Christophe Leroy's message of February 11, 2021 2:44 am:
> As far as I can see, almost all callers of unrecoverable_exception() expect 
> it to never return.
> 
> Can we mark it __noreturn ?

I don't see why not, do_exit is noreturn. We could make die() noreturn 
as well.

> 
> Below is interrupt_exit_kernel_prepare() with then without 
> unrecoverable_exception() declared as 
> __noreturn. (CONFIG_PREEMPT_NONE, and with the BUG_ON() removed)
> 
> With the __noreturn added, we get no stack frame on the likely path

Nice!

Thanks,
Nick

> 
> 03a8 :
>   3a8:81 43 00 84 lwz r10,132(r3)
>   3ac:71 4a 00 02 andi.   r10,r10,2
>   3b0:41 82 00 30 beq 3e0 
>   3b4:80 62 00 70 lwz r3,112(r2)
>   3b8:74 63 00 01 andis.  r3,r3,1
>   3bc:40 82 00 34 bne 3f0 
>   3c0:7d 40 00 a6 mfmsr   r10
>   3c4:55 4a 04 5e rlwinm  r10,r10,0,17,15
>   3c8:7d 40 01 24 mtmsr   r10
>   3cc:7d 20 00 a6 mfmsr   r9
>   3d0:55 29 07 fa rlwinm  r9,r9,0,31,29
>   3d4:55 29 04 5e rlwinm  r9,r9,0,17,15
>   3d8:7d 20 01 24 mtmsr   r9
>   3dc:4e 80 00 20 blr
>   3e0:94 21 ff f0 stwur1,-16(r1)
>   3e4:7c 08 02 a6 mflrr0
>   3e8:90 01 00 14 stw r0,20(r1)
>   3ec:48 00 00 01 bl  3ec 
>   3ec: R_PPC_REL24unrecoverable_exception
>   3f0:38 e2 00 70 addir7,r2,112
>   3f4:3d 00 00 01 lis r8,1
>   3f8:7c c0 38 28 lwarx   r6,0,r7
>   3fc:7c c6 40 78 andcr6,r6,r8
>   400:7c c0 39 2d stwcx.  r6,0,r7
>   404:40 a2 ff f4 bne 3f8 
>   408:38 60 00 01 li  r3,1
>   40c:4b ff ff b4 b   3c0 
> 
> Without the modification:
> 
> 03a8 :
>   3a8:94 21 ff f0 stwur1,-16(r1)
>   3ac:93 e1 00 0c stw r31,12(r1)
>   3b0:81 23 00 84 lwz r9,132(r3)
>   3b4:71 29 00 02 andi.   r9,r9,2
>   3b8:41 82 00 38 beq 3f0 
>   3bc:81 22 00 70 lwz r9,112(r2)
>   3c0:75 23 00 01 andis.  r3,r9,1
>   3c4:40 82 00 4c bne 410 
>   3c8:7d 20 00 a6 mfmsr   r9
>   3cc:55 29 04 5e rlwinm  r9,r9,0,17,15
>   3d0:7d 20 01 24 mtmsr   r9
>   3d4:7d 20 00 a6 mfmsr   r9
>   3d8:55 29 07 fa rlwinm  r9,r9,0,31,29
>   3dc:55 29 04 5e rlwinm  r9,r9,0,17,15
>   3e0:7d 20 01 24 mtmsr   r9
>   3e4:83 e1 00 0c lwz r31,12(r1)
>   3e8:38 21 00 10 addir1,r1,16
>   3ec:4e 80 00 20 blr
>   3f0:7c 08 02 a6 mflrr0
>   3f4:90 01 00 14 stw r0,20(r1)
>   3f8:48 00 00 01 bl  3f8 
>   3f8: R_PPC_REL24unrecoverable_exception
>   3fc:81 22 00 70 lwz r9,112(r2)
>   400:80 01 00 14 lwz r0,20(r1)
>   404:75 23 00 01 andis.  r3,r9,1
>   408:7c 08 03 a6 mtlrr0
>   40c:41 82 ff bc beq 3c8 
>   410:39 02 00 70 addir8,r2,112
>   414:3d 20 00 01 lis r9,1
>   418:7c e0 40 28 lwarx   r7,0,r8
>   41c:7c e7 48 78 andcr7,r7,r9
>   420:7c e0 41 2d stwcx.  r7,0,r8
>   424:40 a2 ff f4 bne 418 
>   428:38 60 00 01 li  r3,1
>   42c:7d 20 00 a6 mfmsr   r9
>   430:55 29 04 5e rlwinm  r9,r9,0,17,15
>   434:7d 20 01 24 mtmsr   r9
>   438:7d 20 00 a6 mfmsr   r9
>   43c:55 29 07 fa rlwinm  r9,r9,0,31,29
>   440:55 29 04 5e rlwinm  r9,r9,0,17,15
>   444:7d 20 01 24 mtmsr   r9
>   448:83 e1 00 0c lwz r31,12(r1)
>   44c:38 21 00 10 addir1,r1,16
>   450:4e 80 00 20 blr
> 


Re: [PATCH v17 03/10] arm64: Use common of_kexec_alloc_and_setup_fdt()

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> From: Rob Herring 
>
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
>
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for arm64.
>
> Signed-off-by: Rob Herring 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/arm64/kernel/machine_kexec_file.c | 180 ++---
>  1 file changed, 8 insertions(+), 172 deletions(-)

Reviewed-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function

2021-02-10 Thread Thiago Jung Bauermann


Lakshmi Ramasubramanian  writes:

> From: Rob Herring 
>
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec.  The differences are either omissions that arm64 should have
> or additional properties that will be ignored.  The setup code can be
> combined and shared by both powerpc and arm64.
>
> The differences relative to the arm64 version:
>  - If /chosen doesn't exist, it will be created (should never happen).
>  - Any old dtb and initrd reserved memory will be released.
>  - The new initrd and elfcorehdr are marked reserved.
>  - "linux,booted-from-kexec" is set.
>
> The differences relative to the powerpc version:
>  - "kaslr-seed" and "rng-seed" may be set.
>  - "linux,elfcorehdr" is set.
>  - Any existing "linux,usable-memory-range" is removed.
>
> Combine the code for setting up the /chosen node in the FDT and updating
> the memory reservation for kexec, for powerpc and arm64, in
> of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
>
> Signed-off-by: Rob Herring 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  drivers/of/Makefile |   6 ++
>  drivers/of/kexec.c  | 258 
>  include/linux/of.h  |  13 +++
>  3 files changed, 277 insertions(+)
>  create mode 100644 drivers/of/kexec.c

Reviewed-by: Thiago Jung Bauermann 

-- 
Thiago Jung Bauermann
IBM Linux Technology Center


Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Lakshmi Ramasubramanian

On 2/10/21 1:39 PM, Mimi Zohar wrote:

On Wed, 2021-02-10 at 15:55 -0500, Mimi Zohar wrote:

On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:

On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian



Ideally, we don't apply the same patch in 2 branches. It looks like
there's a conflict but no real dependence on the above patch (the
ima_buffer part). The conflict seems trivial enough that Linus can
resolve it in the merge window.

Or Mimi can take the whole thing if preferred?


How about I create a topic branch with just the two patches, allowing
both of us to merge it?   There shouldn't be a problem with re-writing
next-integrity history.


The 2 patches are now in the ima-kexec-fixes branch.



Thanks a lot Mimi.

Rob - I will address the 2 comments you'd provided today, and build the 
patches in ima-kexec-fixes branch.


If you have more comments in the v17 patches, please let me know.

thanks,
 -lakshmi



Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Mimi Zohar
On Wed, 2021-02-10 at 15:55 -0500, Mimi Zohar wrote:
> On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:
> > On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
> 
> > Ideally, we don't apply the same patch in 2 branches. It looks like
> > there's a conflict but no real dependence on the above patch (the
> > ima_buffer part). The conflict seems trivial enough that Linus can
> > resolve it in the merge window.
> > 
> > Or Mimi can take the whole thing if preferred?
> 
> How about I create a topic branch with just the two patches, allowing
> both of us to merge it?   There shouldn't be a problem with re-writing
> next-integrity history.

The 2 patches are now in the ima-kexec-fixes branch.

Mimi



Re: [PATCH v5 03/10] powerpc/signal64: Move non-inline functions out of setup_sigcontext()

2021-02-10 Thread Daniel Axtens
"Christopher M. Riedl"  writes:

> On Sun Feb 7, 2021 at 10:44 PM CST, Daniel Axtens wrote:
>> Hi Chris,
>>
>> These two paragraphs are a little confusing and they seem slightly
>> repetitive. But I get the general idea. Two specific comments below:
>
> Umm... yeah only one of those was supposed to be sent. I will reword
> this for the next spin and address the comment below about how it is
> not entirely clear that the inline functions are being moved out.
>
>>
>> > There are non-inline functions which get called in setup_sigcontext() to
>> > save register state to the thread struct. Move these functions into a
>> > separate prepare_setup_sigcontext() function so that
>> > setup_sigcontext() can be refactored later into an "unsafe" version
>> > which assumes an open uaccess window. Non-inline functions should be
>> > avoided when uaccess is open.
>>
>> Why do we want to avoid non-inline functions? We came up with:
>>
>> - we want KUAP protection for as much of the kernel as possible: each
>> extra bit of code run with the window open is another piece of attack
>> surface.
>>
>> - non-inline functions default to traceable, which means we could end
>> up ftracing while uaccess is enabled. That's a pretty big hole in the
>> defences that KUAP provides.
>>
>> I think we've also had problems with the window being opened or closed
>> unexpectedly by various bits of code? So the less code runs in uaccess
>> context the less likely that is to occur.
>
> That is my understanding as well.
>
>>  
>> > The majority of setup_sigcontext() can be refactored to execute in an
>> > "unsafe" context (uaccess window is opened) except for some non-inline
>> > functions. Move these out into a separate prepare_setup_sigcontext()
>> > function which must be called first and before opening up a uaccess
>> > window. A follow-up commit converts setup_sigcontext() to be "unsafe".
>>
>> This was a bit confusing until we realise that you're moving the _calls_
>> to the non-inline functions out, not the non-inline functions
>> themselves.
>>
>> > Signed-off-by: Christopher M. Riedl 
>> > ---
>> >  arch/powerpc/kernel/signal_64.c | 32 +---
>> >  1 file changed, 21 insertions(+), 11 deletions(-)
>> >
>> > diff --git a/arch/powerpc/kernel/signal_64.c 
>> > b/arch/powerpc/kernel/signal_64.c
>> > index f9e4a1ac440f..b211a8ea4f6e 100644
>> > --- a/arch/powerpc/kernel/signal_64.c
>> > +++ b/arch/powerpc/kernel/signal_64.c
>> > @@ -79,6 +79,24 @@ static elf_vrreg_t __user *sigcontext_vmx_regs(struct 
>> > sigcontext __user *sc)
>> >  }
>> >  #endif
>> >  
>> > +static void prepare_setup_sigcontext(struct task_struct *tsk, int 
>> > ctx_has_vsx_region)
>>
>> ctx_has_vsx_region should probably be a bool? Although setup_sigcontext
>> also has it as an int so I guess that's arguable, and maybe it's better
>> to stick with this for constency.
>
> I've been told not to introduce unrelated changes in my patches before
> so chose to keep this as an int for consistency.

Seems reasonable.

>
>>
>> > +{
>> > +#ifdef CONFIG_ALTIVEC
>> > +  /* save altivec registers */
>> > +  if (tsk->thread.used_vr)
>> > +  flush_altivec_to_thread(tsk);
>> > +  if (cpu_has_feature(CPU_FTR_ALTIVEC))
>> > +  tsk->thread.vrsave = mfspr(SPRN_VRSAVE);
>> > +#endif /* CONFIG_ALTIVEC */
>> > +
>> > +  flush_fp_to_thread(tsk);
>> > +
>> > +#ifdef CONFIG_VSX
>> > +  if (tsk->thread.used_vsr && ctx_has_vsx_region)
>> > +  flush_vsx_to_thread(tsk);
>> > +#endif /* CONFIG_VSX */
>>
>> Alternatively, given that this is the only use of ctx_has_vsx_region,
>> mpe suggested that perhaps we could drop it entirely and always
>> flush_vsx if used_vsr. The function is only ever called with either
>> `current` or wth ctx_has_vsx_region set to 1, so in either case I think
>> that's safe? I'm not sure if it would have performance implications.
>
> I think that could work as long as we can guarantee that the context
> passed to swapcontext will always be sufficiently sized if used_vsr,
> which I think *has* to be the case?

I think you're always guaranteed that you'll have a big enough one
in your kernel thread, which is what you end up writing to, iiuc?

>>
>> Should we move this and the altivec ifdef to IS_ENABLED(CONFIG_VSX) etc?
>> I'm not sure if that runs into any problems with things like 'used_vsr'
>> only being defined if CONFIG_VSX is set, but I thought I'd ask.
>
> That's why I didn't use IS_ENABLED(CONFIG_...) here - all of these
> field (used_vr, vrsave, used_vsr) declarations are guarded by #ifdefs :/

Dang. Oh well.
>
>>
>>
>> > +}
>> > +
>> >  /*
>> >   * Set up the sigcontext for the signal frame.
>> >   */
>> > @@ -97,7 +115,6 @@ static long setup_sigcontext(struct sigcontext __user 
>> > *sc,
>> > */
>> >  #ifdef CONFIG_ALTIVEC
>> >elf_vrreg_t __user *v_regs = sigcontext_vmx_regs(sc);
>> > -  unsigned long vrsave;
>> >  #endif
>> >struct pt_regs *regs = tsk->thread.regs;
>> >unsigned long msr = 

Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Mimi Zohar
On Wed, 2021-02-10 at 14:42 -0600, Rob Herring wrote:
> On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
>  wrote:
> >
> > On 2/10/21 9:15 AM, Rob Herring wrote:
> > > On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> > >> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> > >> may verify the IMA signature of the kernel and initramfs, and measure
> > >> it.  The command line parameters passed to the kernel in the kexec call
> > >> may also be measured by IMA.  A remote attestation service can verify
> > >> a TPM quote based on the TPM event log, the IMA measurement list, and
> > >> the TPM PCR data.  This can be achieved only if the IMA measurement log
> > >> is carried over from the current kernel to the next kernel across
> > >> the kexec call.
> > >>
> > >> powerpc already supports carrying forward the IMA measurement log on
> > >> kexec.  This patch set adds support for carrying forward the IMA
> > >> measurement log on kexec on ARM64.
> > >>
> > >> This patch set moves the platform independent code defined for powerpc
> > >> such that it can be reused for other platforms as well.  A chosen node
> > >> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> > >> the address and the size of the memory reserved to carry
> > >> the IMA measurement log.
> > >>
> > >> This patch set has been tested for ARM64 platform using QEMU.
> > >> I would like help from the community for testing this change on powerpc.
> > >> Thanks.
> > >>
> > >> This patch set is based on
> > >> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec 
> > >> syscall")
> > >> in 
> > >> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> > >> "next-integrity" branch.
> > >
> > > Is that a hard dependency still? Given this is now almost entirely
> > > deleting arch code and adding drivers/of/ code, I was going to apply it.
> > >
> >
> > I tried applying the patches in Linus' mainline branch -
> > PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch
> > doesn't apply.
> >
> > But if I apply the dependent patch set (link given below), all the
> > patches in this patch set apply fine.
> >
> > https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nra...@linux.microsoft.com/
> 
> Ideally, we don't apply the same patch in 2 branches. It looks like
> there's a conflict but no real dependence on the above patch (the
> ima_buffer part). The conflict seems trivial enough that Linus can
> resolve it in the merge window.
> 
> Or Mimi can take the whole thing if preferred?

How about I create a topic branch with just the two patches, allowing
both of us to merge it?   There shouldn't be a problem with re-writing
next-integrity history.

Mimi




Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Rob Herring
On Wed, Feb 10, 2021 at 11:33 AM Lakshmi Ramasubramanian
 wrote:
>
> On 2/10/21 9:15 AM, Rob Herring wrote:
> > On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> >> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> >> may verify the IMA signature of the kernel and initramfs, and measure
> >> it.  The command line parameters passed to the kernel in the kexec call
> >> may also be measured by IMA.  A remote attestation service can verify
> >> a TPM quote based on the TPM event log, the IMA measurement list, and
> >> the TPM PCR data.  This can be achieved only if the IMA measurement log
> >> is carried over from the current kernel to the next kernel across
> >> the kexec call.
> >>
> >> powerpc already supports carrying forward the IMA measurement log on
> >> kexec.  This patch set adds support for carrying forward the IMA
> >> measurement log on kexec on ARM64.
> >>
> >> This patch set moves the platform independent code defined for powerpc
> >> such that it can be reused for other platforms as well.  A chosen node
> >> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> >> the address and the size of the memory reserved to carry
> >> the IMA measurement log.
> >>
> >> This patch set has been tested for ARM64 platform using QEMU.
> >> I would like help from the community for testing this change on powerpc.
> >> Thanks.
> >>
> >> This patch set is based on
> >> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec 
> >> syscall")
> >> in 
> >> https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> >> "next-integrity" branch.
> >
> > Is that a hard dependency still? Given this is now almost entirely
> > deleting arch code and adding drivers/of/ code, I was going to apply it.
> >
>
> I tried applying the patches in Linus' mainline branch -
> PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch
> doesn't apply.
>
> But if I apply the dependent patch set (link given below), all the
> patches in this patch set apply fine.
>
> https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nra...@linux.microsoft.com/

Ideally, we don't apply the same patch in 2 branches. It looks like
there's a conflict but no real dependence on the above patch (the
ima_buffer part). The conflict seems trivial enough that Linus can
resolve it in the merge window.

Or Mimi can take the whole thing if preferred?

Rob


[PATCH] arm64: defconfig: enable modern virtio pci device

2021-02-10 Thread Anders Roxell
Since patch ("virtio-pci: introduce modern device module") got added it
is not possible to boot a defconfig kernel in qemu with a virtio pci
device.  Add CONFIG_VIRTIO_PCI_MODERN=y fragment makes the kernel able
to boot.

Signed-off-by: Anders Roxell 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 arch/arm64/configs/defconfig| 1 +
 arch/mips/configs/loongson3_defconfig   | 1 +
 arch/mips/configs/malta_kvm_guest_defconfig | 1 +
 arch/powerpc/configs/guest.config   | 1 +
 arch/riscv/configs/defconfig| 1 +
 arch/riscv/configs/rv32_defconfig   | 1 +
 arch/xtensa/configs/virt_defconfig  | 1 +
 kernel/configs/kvm_guest.config | 1 +
 9 files changed, 9 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 3823da605430..02297ed49b20 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -972,6 +972,7 @@ CONFIG_DW_DMAC=y
 CONFIG_RCAR_DMAC=y
 CONFIG_RENESAS_USB_DMAC=m
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_STAGING=y
 CONFIG_MFD_NVEC=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 83c28da85834..8334e9cb4608 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -910,6 +910,7 @@ CONFIG_TI_K3_UDMA_GLUE_LAYER=y
 CONFIG_VFIO=y
 CONFIG_VFIO_PCI=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_XEN_GNTDEV=y
diff --git a/arch/mips/configs/loongson3_defconfig 
b/arch/mips/configs/loongson3_defconfig
index 0e79f81217bc..ac5f2dcbffb1 100644
--- a/arch/mips/configs/loongson3_defconfig
+++ b/arch/mips/configs/loongson3_defconfig
@@ -324,6 +324,7 @@ CONFIG_RTC_DRV_CMOS=y
 CONFIG_RTC_DRV_GOLDFISH=y
 CONFIG_DMADEVICES=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=m
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/mips/configs/malta_kvm_guest_defconfig 
b/arch/mips/configs/malta_kvm_guest_defconfig
index 9185e0a0aa45..043633cdb406 100644
--- a/arch/mips/configs/malta_kvm_guest_defconfig
+++ b/arch/mips/configs/malta_kvm_guest_defconfig
@@ -332,6 +332,7 @@ CONFIG_RTC_DRV_CMOS=y
 CONFIG_UIO=m
 CONFIG_UIO_CIF=m
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
 CONFIG_EXT2_FS=y
diff --git a/arch/powerpc/configs/guest.config 
b/arch/powerpc/configs/guest.config
index 209f58515d88..fbff632c8633 100644
--- a/arch/powerpc/configs/guest.config
+++ b/arch/powerpc/configs/guest.config
@@ -5,6 +5,7 @@ CONFIG_NET_FAILOVER=y
 CONFIG_VIRTIO_CONSOLE=y
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_KVM_GUEST=y
 CONFIG_EPAPR_PARAVIRT=y
 CONFIG_VIRTIO_BALLOON=y
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 8c3d1e451703..b7fa7a1a0c6d 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -85,6 +85,7 @@ CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/riscv/configs/rv32_defconfig 
b/arch/riscv/configs/rv32_defconfig
index 2c2cda6cc1c5..68296101fa06 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -84,6 +84,7 @@ CONFIG_MMC=y
 CONFIG_MMC_SPI=y
 CONFIG_RTC_CLASS=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_INPUT=y
 CONFIG_VIRTIO_MMIO=y
diff --git a/arch/xtensa/configs/virt_defconfig 
b/arch/xtensa/configs/virt_defconfig
index 6d1387dfa96f..7fad1c2454fd 100644
--- a/arch/xtensa/configs/virt_defconfig
+++ b/arch/xtensa/configs/virt_defconfig
@@ -74,6 +74,7 @@ CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_INPUT=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
diff --git a/kernel/configs/kvm_guest.config b/kernel/configs/kvm_guest.config
index 208481d91090..8dea6df20006 100644
--- a/kernel/configs/kvm_guest.config
+++ b/kernel/configs/kvm_guest.config
@@ -22,6 +22,7 @@ CONFIG_S390_GUEST=y
 CONFIG_VIRTIO=y
 CONFIG_VIRTIO_MENU=y
 CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_PCI_MODERN=y
 CONFIG_VIRTIO_BLK=y
 CONFIG_VIRTIO_CONSOLE=y
 CONFIG_VIRTIO_NET=y
-- 
2.30.0



Re: [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name

2021-02-10 Thread Serge Semin
On Wed, Feb 10, 2021 at 10:21:47AM -0800, Florian Fainelli wrote:
> On 2/10/21 9:28 AM, Serge Semin wrote:
> > As the subject states this series is an attempt to harmonize the xHCI,
> > EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> > framework of the patchset [1].
> > 
> > Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> > controllers with "synopsys,"-vendor prefix compatible string in favor of
> > the ones with valid "snps,"-prefix. It's done in all the DTS files,
> > which have been unfortunate to define such nodes.
> > 
> > Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
> > declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
> > been erroneously declared as boolean while having uint32 type. Neil said
> > it was ok to init that property with 0x20 value.
> > 
> > Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
> > and DWC USB3 DT nodes name as in accordance with their DT schema the
> > corresponding node name is suppose to comply with the Generic USB HCD DT
> > schema, which requires the USB nodes to have the name acceptable by the
> > regexp: "^usb(@.*)?". Such requirement had been applicable even before we
> > introduced the new DT schema in [1], but as we can see it hasn't been
> > strictly implemented for a lot the DTS files. Since DT schema is now
> > available the automated DTS validation shall make sure that the rule isn't
> > violated.
> > 
> > Note most of these patches have been a part of the last three patches of
> > [1]. But since there is no way to have them merged in in a combined
> > manner, I had to move them to the dedicated series and split them up so to
> > be accepted by the corresponding subsystem maintainers one-by-one.
> > 
> > [1] Link: 
> > https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
> > Changelog v1:
> > - As Krzysztof suggested I've created a script which checked whether the
> >   node names had been also updated in all the depended dts files. As a
> >   result I found two more files which should have been also modified:
> >   arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
> > - Correct the USB DWC3 nodes name found in
> >   arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
> > 
> > Link: 
> > https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
> > Changelog v2:
> > - Drop the patch:
> >   [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
> >   and get back the one which marks the "synopsys,dwc3" compatible string
> >   as deprecated into the DT schema related series.
> > - Drop the patches:
> >   [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
> >   [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
> >   [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
> >   [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
> >   [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
> >   [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
> >   [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
> >   [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
> >   [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
> >   since they have been applied to the corresponding maintainers repos.
> > - Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
> >   sub-node and falling back to the "dwc3@"-prefixed one on failure.
> > 
> > Link: 
> > https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
> > Changelog v3:
> > - Drop the patches:
> >   [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
> >   [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes 
> > name
> >   [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
> >   [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT 
> > nodes name
> >   [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
> >   since they have been applied to the corresponding maintainers repos.
> > 
> > Link: 
> > https://lore.kernel.org/linux-usb/20201205155621.3045-1-sergey.se...@baikalelectronics.ru
> > Changelog v4:
> > - Just resend.
> > 
> > Link: 
> > https://lore.kernel.org/linux-usb/20201210091756.18057-1-sergey.se...@baikalelectronics.ru/
> > Changelog v5:
> > - Drop the patch:
> >   [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
> >   since it has 

Re: [PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name

2021-02-10 Thread Florian Fainelli
On 2/10/21 9:28 AM, Serge Semin wrote:
> As the subject states this series is an attempt to harmonize the xHCI,
> EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
> framework of the patchset [1].
> 
> Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
> controllers with "synopsys,"-vendor prefix compatible string in favor of
> the ones with valid "snps,"-prefix. It's done in all the DTS files,
> which have been unfortunate to define such nodes.
> 
> Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
> declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
> been erroneously declared as boolean while having uint32 type. Neil said
> it was ok to init that property with 0x20 value.
> 
> Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
> and DWC USB3 DT nodes name as in accordance with their DT schema the
> corresponding node name is suppose to comply with the Generic USB HCD DT
> schema, which requires the USB nodes to have the name acceptable by the
> regexp: "^usb(@.*)?". Such requirement had been applicable even before we
> introduced the new DT schema in [1], but as we can see it hasn't been
> strictly implemented for a lot the DTS files. Since DT schema is now
> available the automated DTS validation shall make sure that the rule isn't
> violated.
> 
> Note most of these patches have been a part of the last three patches of
> [1]. But since there is no way to have them merged in in a combined
> manner, I had to move them to the dedicated series and split them up so to
> be accepted by the corresponding subsystem maintainers one-by-one.
> 
> [1] Link: 
> https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
> Changelog v1:
> - As Krzysztof suggested I've created a script which checked whether the
>   node names had been also updated in all the depended dts files. As a
>   result I found two more files which should have been also modified:
>   arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
> - Correct the USB DWC3 nodes name found in
>   arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.
> 
> Link: 
> https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
> Changelog v2:
> - Drop the patch:
>   [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
>   and get back the one which marks the "synopsys,dwc3" compatible string
>   as deprecated into the DT schema related series.
> - Drop the patches:
>   [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
>   [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
>   [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
>   [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
>   [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
>   [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
>   [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
>   [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
>   [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
>   [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
>   [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
>   since they have been applied to the corresponding maintainers repos.
> - Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
>   sub-node and falling back to the "dwc3@"-prefixed one on failure.
> 
> Link: 
> https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
> Changelog v3:
> - Drop the patches:
>   [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
>   [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
>   [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
>   [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
>   [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes 
> name
>   [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
>   [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes 
> name
>   [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
>   since they have been applied to the corresponding maintainers repos.
> 
> Link: 
> https://lore.kernel.org/linux-usb/20201205155621.3045-1-sergey.se...@baikalelectronics.ru
> Changelog v4:
> - Just resend.
> 
> Link: 
> https://lore.kernel.org/linux-usb/20201210091756.18057-1-sergey.se...@baikalelectronics.ru/
> Changelog v5:
> - Drop the patch:
>   [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
>   since it has been applied to the corresponding maintainers repos.
> - Get back the patch:
>   [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
>   as it has been missing in the kernel 5.11-rc7
> - Rebase onto the kernel 5.11-rc7
> 
> Link: 

Re: [PATCH v17 05/10] powerpc: Move ima buffer fields to struct kimage

2021-02-10 Thread Lakshmi Ramasubramanian

On 2/10/21 9:20 AM, Rob Herring wrote:

On Tue, Feb 09, 2021 at 10:21:55AM -0800, Lakshmi Ramasubramanian wrote:

The fields ima_buffer_addr and ima_buffer_size in "struct kimage_arch"
for powerpc are used to carry forward the IMA measurement list across
kexec system call.  These fields are not architecture specific, but are
currently limited to powerpc.

arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
sets ima_buffer_addr and ima_buffer_size for the kexec system call.
This function does not have architecture specific code, but is
currently limited to powerpc.

Move ima_buffer_addr and ima_buffer_size to "struct kimage".
Rename arch_ima_add_kexec_buffer() to of_ima_add_kexec_buffer()
and move it in drivers/of/kexec.c.

Co-developed-by: Prakhar Srivastava 
Signed-off-by: Prakhar Srivastava 
Signed-off-by: Lakshmi Ramasubramanian 
Suggested-by: Will Deacon 
---
  arch/powerpc/include/asm/ima.h |  3 ---
  arch/powerpc/include/asm/kexec.h   |  5 -
  arch/powerpc/kexec/ima.c   | 29 ++---
  drivers/of/kexec.c | 23 +++
  include/linux/kexec.h  |  3 +++
  include/linux/of.h |  5 +
  security/integrity/ima/ima_kexec.c |  3 ++-
  7 files changed, 39 insertions(+), 32 deletions(-)



diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 469e09613cdd..9f33d215b9f2 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -63,6 +63,29 @@ static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long 
start, unsigned lon
return -ENOENT;
  }
  
+#ifdef CONFIG_IMA_KEXEC

+/**
+ * of_ima_add_kexec_buffer - Add IMA buffer for next kernel
+ *
+ * @image: kimage struct to set IMA buffer data
+ * @load_addr: Starting address where IMA buffer is loaded at
+ * @size: Number of bytes in the IMA buffer
+ *
+ * Use this function to pass on the IMA buffer information to
+ * the next kernel across kexec system call.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int of_ima_add_kexec_buffer(struct kimage *image,
+   unsigned long load_addr, size_t size)
+{
+   image->ima_buffer_addr = load_addr;
+   image->ima_buffer_size = size;
+


There's nothing DT specific about this function, so this is the wrong
place for it. I would just remove it and directly set the members.


Will do.

 -lakshmi




Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function

2021-02-10 Thread Lakshmi Ramasubramanian

On 2/10/21 9:23 AM, Rob Herring wrote:

On Tue, Feb 09, 2021 at 10:21:52AM -0800, Lakshmi Ramasubramanian wrote:

From: Rob Herring 

Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec.  The differences are either omissions that arm64 should have
or additional properties that will be ignored.  The setup code can be
combined and shared by both powerpc and arm64.

The differences relative to the arm64 version:
  - If /chosen doesn't exist, it will be created (should never happen).
  - Any old dtb and initrd reserved memory will be released.
  - The new initrd and elfcorehdr are marked reserved.
  - "linux,booted-from-kexec" is set.

The differences relative to the powerpc version:
  - "kaslr-seed" and "rng-seed" may be set.
  - "linux,elfcorehdr" is set.
  - Any existing "linux,usable-memory-range" is removed.

Combine the code for setting up the /chosen node in the FDT and updating
the memory reservation for kexec, for powerpc and arm64, in
of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".

Signed-off-by: Rob Herring 
Signed-off-by: Lakshmi Ramasubramanian 
---
  drivers/of/Makefile |   6 ++
  drivers/of/kexec.c  | 258 
  include/linux/of.h  |  13 +++
  3 files changed, 277 insertions(+)
  create mode 100644 drivers/of/kexec.c




diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..f0eff5e84353 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -560,6 +560,19 @@ int of_map_id(struct device_node *np, u32 id,
  
  phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
  
+/*

+ * Additional space needed for the buffer to build the new FDT
+ * so that we can add initrd, bootargs, kaslr-seed, rng-seed,
+ * userable-memory-range and elfcorehdr.
+ */
+#define FDT_EXTRA_SPACE 0x1000


No need for this to be public now. Move it to of/kexec.c.



Will do.

 -lakshmi




Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Lakshmi Ramasubramanian

On 2/10/21 9:15 AM, Rob Herring wrote:

On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:

On kexec file load Integrity Measurement Architecture (IMA) subsystem
may verify the IMA signature of the kernel and initramfs, and measure
it.  The command line parameters passed to the kernel in the kexec call
may also be measured by IMA.  A remote attestation service can verify
a TPM quote based on the TPM event log, the IMA measurement list, and
the TPM PCR data.  This can be achieved only if the IMA measurement log
is carried over from the current kernel to the next kernel across
the kexec call.

powerpc already supports carrying forward the IMA measurement log on
kexec.  This patch set adds support for carrying forward the IMA
measurement log on kexec on ARM64.

This patch set moves the platform independent code defined for powerpc
such that it can be reused for other platforms as well.  A chosen node
"linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
the address and the size of the memory reserved to carry
the IMA measurement log.

This patch set has been tested for ARM64 platform using QEMU.
I would like help from the community for testing this change on powerpc.
Thanks.

This patch set is based on
commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
"next-integrity" branch.


Is that a hard dependency still? Given this is now almost entirely
deleting arch code and adding drivers/of/ code, I was going to apply it.



I tried applying the patches in Linus' mainline branch -
PATCH #5 0005-powerpc-Move-ima-buffer-fields-to-struct-kimage.patch 
doesn't apply.


But if I apply the dependent patch set (link given below), all the 
patches in this patch set apply fine.


https://patchwork.kernel.org/project/linux-integrity/patch/20210204174951.25771-2-nra...@linux.microsoft.com/

thanks,
 -lakshmi




[PATCH RESEND v6 00/10] dt-bindings: usb: Harmonize xHCI/EHCI/OHCI/DWC3 nodes name

2021-02-10 Thread Serge Semin
As the subject states this series is an attempt to harmonize the xHCI,
EHCI, OHCI and DWC USB3 DT nodes with the DT schema introduced in the
framework of the patchset [1].

Firstly as Krzysztof suggested we've deprecated a support of DWC USB3
controllers with "synopsys,"-vendor prefix compatible string in favor of
the ones with valid "snps,"-prefix. It's done in all the DTS files,
which have been unfortunate to define such nodes.

Secondly we suggest to fix the snps,quirk-frame-length-adjustment property
declaration in the Amlogic meson-g12-common.dtsi DTS file, since it has
been erroneously declared as boolean while having uint32 type. Neil said
it was ok to init that property with 0x20 value.

Thirdly the main part of the patchset concern fixing the xHCI, EHCI/OHCI
and DWC USB3 DT nodes name as in accordance with their DT schema the
corresponding node name is suppose to comply with the Generic USB HCD DT
schema, which requires the USB nodes to have the name acceptable by the
regexp: "^usb(@.*)?". Such requirement had been applicable even before we
introduced the new DT schema in [1], but as we can see it hasn't been
strictly implemented for a lot the DTS files. Since DT schema is now
available the automated DTS validation shall make sure that the rule isn't
violated.

Note most of these patches have been a part of the last three patches of
[1]. But since there is no way to have them merged in in a combined
manner, I had to move them to the dedicated series and split them up so to
be accepted by the corresponding subsystem maintainers one-by-one.

[1] Link: 
https://lore.kernel.org/linux-usb/20201014101402.18271-1-sergey.se...@baikalelectronics.ru/
Changelog v1:
- As Krzysztof suggested I've created a script which checked whether the
  node names had been also updated in all the depended dts files. As a
  result I found two more files which should have been also modified:
  arch/arc/boot/dts/{axc003.dtsi,axc003_idu.dtsi}
- Correct the USB DWC3 nodes name found in
  arch/arm64/boot/dts/apm/{apm-storm.dtsi,apm-shadowcat.dtsi} too.

Link: 
https://lore.kernel.org/linux-usb/20201020115959.2658-1-sergey.se...@baikalelectronics.ru
Changelog v2:
- Drop the patch:
  [PATCH 01/29] usb: dwc3: Discard synopsys,dwc3 compatibility string
  and get back the one which marks the "synopsys,dwc3" compatible string
  as deprecated into the DT schema related series.
- Drop the patches:
  [PATCH 03/29] arm: dts: am437x: Correct DWC USB3 compatible string
  [PATCH 04/29] arm: dts: exynos: Correct DWC USB3 compatible string
  [PATCH 07/29] arm: dts: bcm53x: Harmonize EHCI/OHCI DT nodes name
  [PATCH 08/29] arm: dts: stm32: Harmonize EHCI/OHCI DT nodes name
  [PATCH 16/29] arm: dts: bcm5301x: Harmonize xHCI DT nodes name
  [PATCH 19/29] arm: dts: exynos: Harmonize DWC USB3 DT nodes name
  [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  [PATCH 22/29] arm: dts: omap5: Harmonize DWC USB3 DT nodes name
  [PATCH 24/29] arm64: dts: allwinner: h6: Harmonize DWC USB3 DT nodes name
  [PATCH 26/29] arm64: dts: exynos: Harmonize DWC USB3 DT nodes name
  [PATCH 27/29] arm64: dts: layerscape: Harmonize DWC USB3 DT nodes name
  since they have been applied to the corresponding maintainers repos.
- Fix drivers/usb/dwc3/dwc3-qcom.c to be looking for the "usb@"-prefixed
  sub-node and falling back to the "dwc3@"-prefixed one on failure.

Link: 
https://lore.kernel.org/linux-usb/2020091552.15593-1-sergey.se...@baikalelectronics.ru
Changelog v3:
- Drop the patches:
  [PATCH v2 04/18] arm: dts: hisi-x5hd2: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 06/18] arm64: dts: hisi: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 07/18] mips: dts: jz47x: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 08/18] mips: dts: sead3: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 09/18] mips: dts: ralink: mt7628a: Harmonize EHCI/OHCI DT nodes name
  [PATCH v2 11/18] arm64: dts: marvell: cp11x: Harmonize xHCI DT nodes name
  [PATCH v2 12/18] arm: dts: marvell: armada-375: Harmonize DWC USB3 DT nodes 
name
  [PATCH v2 16/18] arm64: dts: hi3660: Harmonize DWC USB3 DT nodes name
  since they have been applied to the corresponding maintainers repos.

Link: 
https://lore.kernel.org/linux-usb/20201205155621.3045-1-sergey.se...@baikalelectronics.ru
Changelog v4:
- Just resend.

Link: 
https://lore.kernel.org/linux-usb/20201210091756.18057-1-sergey.se...@baikalelectronics.ru/
Changelog v5:
- Drop the patch:
  [PATCH v4 02/10] arm64: dts: amlogic: meson-g12: Set FL-adj property value
  since it has been applied to the corresponding maintainers repos.
- Get back the patch:
  [PATCH 21/29] arm: dts: ls1021a: Harmonize DWC USB3 DT nodes name
  as it has been missing in the kernel 5.11-rc7
- Rebase onto the kernel 5.11-rc7

Link: 
https://lore.kernel.org/lkml/20210208135154.6645-1-sergey.se...@baikalelectronics.ru/
Changelog v6:
- Just resend and add linux-usb.vger.kernel.org to the list of Ccecipients.

Cc: Vineet Gupta 
Cc: Rafal Milecki 
Cc: Wei Xu 
Cc: 

[PATCH v6 05/10] powerpc: dts: akebono: Harmonize EHCI/OHCI DT nodes name

2021-02-10 Thread Serge Semin
In accordance with the Generic EHCI/OHCI bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "generic-ehci" and "generic-ohci"-compatible
nodes are correctly named.

Signed-off-by: Serge Semin 
Acked-by: Krzysztof Kozlowski 
---
 arch/powerpc/boot/dts/akebono.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/boot/dts/akebono.dts 
b/arch/powerpc/boot/dts/akebono.dts
index df18f8dc4642..343326c30380 100644
--- a/arch/powerpc/boot/dts/akebono.dts
+++ b/arch/powerpc/boot/dts/akebono.dts
@@ -126,7 +126,7 @@ SATA0: sata@301 {
interrupts = <93 2>;
};
 
-   EHCI0: ehci@3001000 {
+   EHCI0: usb@3001000 {
compatible = "ibm,476gtr-ehci", "generic-ehci";
reg = <0x300 0x1000 0x0 0x1>;
interrupt-parent = <>;
@@ -140,14 +140,14 @@ SD0: sd@300 {
interrupt-parent = <>;
};
 
-   OHCI0: ohci@3001001 {
+   OHCI0: usb@3001001 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1001 0x0 0x1>;
interrupt-parent = <>;
interrupts = <89 1>;
};
 
-   OHCI1: ohci@3001002 {
+   OHCI1: usb@3001002 {
compatible = "ibm,476gtr-ohci", "generic-ohci";
reg = <0x300 0x1002 0x0 0x1>;
interrupt-parent = <>;
-- 
2.30.0



Re: [PATCH v17 03/10] arm64: Use common of_kexec_alloc_and_setup_fdt()

2021-02-10 Thread Will Deacon
On Tue, Feb 09, 2021 at 10:21:53AM -0800, Lakshmi Ramasubramanian wrote:
> From: Rob Herring 
> 
> The code for setting up the /chosen node in the device tree
> and updating the memory reservation for the next kernel has been
> moved to of_kexec_alloc_and_setup_fdt() defined in "drivers/of/kexec.c".
> 
> Use the common of_kexec_alloc_and_setup_fdt() to setup the device tree
> and update the memory reservation for kexec for arm64.
> 
> Signed-off-by: Rob Herring 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  arch/arm64/kernel/machine_kexec_file.c | 180 ++---
>  1 file changed, 8 insertions(+), 172 deletions(-)

I mean, of course I'm going to Ack that!

Acked-by: Will Deacon 

Will


Re: [PATCH v17 02/10] of: Add a common kexec FDT setup function

2021-02-10 Thread Rob Herring
On Tue, Feb 09, 2021 at 10:21:52AM -0800, Lakshmi Ramasubramanian wrote:
> From: Rob Herring 
> 
> Both arm64 and powerpc do essentially the same FDT /chosen setup for
> kexec.  The differences are either omissions that arm64 should have
> or additional properties that will be ignored.  The setup code can be
> combined and shared by both powerpc and arm64.
> 
> The differences relative to the arm64 version:
>  - If /chosen doesn't exist, it will be created (should never happen).
>  - Any old dtb and initrd reserved memory will be released.
>  - The new initrd and elfcorehdr are marked reserved.
>  - "linux,booted-from-kexec" is set.
> 
> The differences relative to the powerpc version:
>  - "kaslr-seed" and "rng-seed" may be set.
>  - "linux,elfcorehdr" is set.
>  - Any existing "linux,usable-memory-range" is removed.
> 
> Combine the code for setting up the /chosen node in the FDT and updating
> the memory reservation for kexec, for powerpc and arm64, in
> of_kexec_alloc_and_setup_fdt() and move it to "drivers/of/kexec.c".
> 
> Signed-off-by: Rob Herring 
> Signed-off-by: Lakshmi Ramasubramanian 
> ---
>  drivers/of/Makefile |   6 ++
>  drivers/of/kexec.c  | 258 
>  include/linux/of.h  |  13 +++
>  3 files changed, 277 insertions(+)
>  create mode 100644 drivers/of/kexec.c
> 
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 6e1e5212f058..c13b982084a3 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -14,4 +14,10 @@ obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
>  obj-$(CONFIG_OF_NUMA) += of_numa.o
>  
> +ifdef CONFIG_KEXEC_FILE
> +ifdef CONFIG_OF_FLATTREE
> +obj-y+= kexec.o
> +endif
> +endif
> +
>  obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
> new file mode 100644
> index ..469e09613cdd
> --- /dev/null
> +++ b/drivers/of/kexec.c
> @@ -0,0 +1,258 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2020 Arm Limited
> + *
> + * Based on arch/arm64/kernel/machine_kexec_file.c:
> + *  Copyright (C) 2018 Linaro Limited
> + *
> + * And arch/powerpc/kexec/file_load.c:
> + *  Copyright (C) 2016  IBM Corporation
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* relevant device tree properties */
> +#define FDT_PROP_KEXEC_ELFHDR"linux,elfcorehdr"
> +#define FDT_PROP_MEM_RANGE   "linux,usable-memory-range"
> +#define FDT_PROP_INITRD_START"linux,initrd-start"
> +#define FDT_PROP_INITRD_END  "linux,initrd-end"
> +#define FDT_PROP_BOOTARGS"bootargs"
> +#define FDT_PROP_KASLR_SEED  "kaslr-seed"
> +#define FDT_PROP_RNG_SEED"rng-seed"
> +#define RNG_SEED_SIZE128
> +
> +/**
> + * fdt_find_and_del_mem_rsv - delete memory reservation with given address 
> and size
> + *
> + * @fdt: Flattened device tree for the current kernel.
> + * @start:   Starting address of the reserved memory.
> + * @size:Size of the reserved memory.
> + *
> + * Return: 0 on success, or negative errno on error.
> + */
> +static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned 
> long size)
> +{
> + int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
> +
> + for (i = 0; i < num_rsvs; i++) {
> + u64 rsv_start, rsv_size;
> +
> + ret = fdt_get_mem_rsv(fdt, i, _start, _size);
> + if (ret) {
> + pr_err("Malformed device tree.\n");
> + return -EINVAL;
> + }
> +
> + if (rsv_start == start && rsv_size == size) {
> + ret = fdt_del_mem_rsv(fdt, i);
> + if (ret) {
> + pr_err("Error deleting device tree 
> reservation.\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> + }
> + }
> +
> + return -ENOENT;
> +}
> +
> +/*
> + * of_kexec_alloc_and_setup_fdt - Alloc and setup a new Flattened Device Tree
> + *
> + * @image:   kexec image being loaded.
> + * @initrd_load_addr:Address where the next initrd will be loaded.
> + * @initrd_len:  Size of the next initrd, or 0 if there will be 
> none.
> + * @cmdline: Command line for the next kernel, or NULL if there will
> + *   be none.
> + *
> + * Return: fdt on success, or NULL errno on error.
> + */
> +void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
> +unsigned long initrd_load_addr,
> +unsigned long initrd_len,
> +const char *cmdline)
> +{
> + void *fdt;
> + int ret, chosen_node;
> + const void *prop;
> + unsigned long fdt_size;
> +
> + fdt_size = fdt_totalsize(initial_boot_params) +
> +(cmdline ? strlen(cmdline) : 0) +
> +

Re: [PATCH v17 05/10] powerpc: Move ima buffer fields to struct kimage

2021-02-10 Thread Rob Herring
On Tue, Feb 09, 2021 at 10:21:55AM -0800, Lakshmi Ramasubramanian wrote:
> The fields ima_buffer_addr and ima_buffer_size in "struct kimage_arch"
> for powerpc are used to carry forward the IMA measurement list across
> kexec system call.  These fields are not architecture specific, but are
> currently limited to powerpc.
> 
> arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c"
> sets ima_buffer_addr and ima_buffer_size for the kexec system call.
> This function does not have architecture specific code, but is
> currently limited to powerpc.
> 
> Move ima_buffer_addr and ima_buffer_size to "struct kimage".
> Rename arch_ima_add_kexec_buffer() to of_ima_add_kexec_buffer()
> and move it in drivers/of/kexec.c.
> 
> Co-developed-by: Prakhar Srivastava 
> Signed-off-by: Prakhar Srivastava 
> Signed-off-by: Lakshmi Ramasubramanian 
> Suggested-by: Will Deacon 
> ---
>  arch/powerpc/include/asm/ima.h |  3 ---
>  arch/powerpc/include/asm/kexec.h   |  5 -
>  arch/powerpc/kexec/ima.c   | 29 ++---
>  drivers/of/kexec.c | 23 +++
>  include/linux/kexec.h  |  3 +++
>  include/linux/of.h |  5 +
>  security/integrity/ima/ima_kexec.c |  3 ++-
>  7 files changed, 39 insertions(+), 32 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/ima.h b/arch/powerpc/include/asm/ima.h
> index ead488cf3981..51f64fd06c19 100644
> --- a/arch/powerpc/include/asm/ima.h
> +++ b/arch/powerpc/include/asm/ima.h
> @@ -14,9 +14,6 @@ static inline void remove_ima_buffer(void *fdt, int 
> chosen_node) {}
>  #endif
>  
>  #ifdef CONFIG_IMA_KEXEC
> -int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> -   size_t size);
> -
>  int setup_ima_buffer(const struct kimage *image, void *fdt, int chosen_node);
>  #else
>  static inline int setup_ima_buffer(const struct kimage *image, void *fdt,
> diff --git a/arch/powerpc/include/asm/kexec.h 
> b/arch/powerpc/include/asm/kexec.h
> index bdd0ddb9ac4d..ecf88533d6b4 100644
> --- a/arch/powerpc/include/asm/kexec.h
> +++ b/arch/powerpc/include/asm/kexec.h
> @@ -112,11 +112,6 @@ struct kimage_arch {
>   unsigned long elf_headers_sz;
>   void *elf_headers;
>   void *fdt;
> -
> -#ifdef CONFIG_IMA_KEXEC
> - phys_addr_t ima_buffer_addr;
> - size_t ima_buffer_size;
> -#endif
>  };
>  
>  char *setup_kdump_cmdline(struct kimage *image, char *cmdline,
> diff --git a/arch/powerpc/kexec/ima.c b/arch/powerpc/kexec/ima.c
> index 720e50e490b6..ed38125e2f87 100644
> --- a/arch/powerpc/kexec/ima.c
> +++ b/arch/powerpc/kexec/ima.c
> @@ -128,23 +128,6 @@ void remove_ima_buffer(void *fdt, int chosen_node)
>  }
>  
>  #ifdef CONFIG_IMA_KEXEC
> -/**
> - * arch_ima_add_kexec_buffer - do arch-specific steps to add the IMA buffer
> - *
> - * Architectures should use this function to pass on the IMA buffer
> - * information to the next kernel.
> - *
> - * Return: 0 on success, negative errno on error.
> - */
> -int arch_ima_add_kexec_buffer(struct kimage *image, unsigned long load_addr,
> -   size_t size)
> -{
> - image->arch.ima_buffer_addr = load_addr;
> - image->arch.ima_buffer_size = size;
> -
> - return 0;
> -}
> -
>  static int write_number(void *p, u64 value, int cells)
>  {
>   if (cells == 1) {
> @@ -180,7 +163,7 @@ int setup_ima_buffer(const struct kimage *image, void 
> *fdt, int chosen_node)
>   u8 value[16];
>  
>   remove_ima_buffer(fdt, chosen_node);
> - if (!image->arch.ima_buffer_size)
> + if (!image->ima_buffer_size)
>   return 0;
>  
>   ret = get_addr_size_cells(_cells, _cells);
> @@ -192,11 +175,11 @@ int setup_ima_buffer(const struct kimage *image, void 
> *fdt, int chosen_node)
>   if (entry_size > sizeof(value))
>   return -EINVAL;
>  
> - ret = write_number(value, image->arch.ima_buffer_addr, addr_cells);
> + ret = write_number(value, image->ima_buffer_addr, addr_cells);
>   if (ret)
>   return ret;
>  
> - ret = write_number(value + 4 * addr_cells, image->arch.ima_buffer_size,
> + ret = write_number(value + 4 * addr_cells, image->ima_buffer_size,
>  size_cells);
>   if (ret)
>   return ret;
> @@ -206,13 +189,13 @@ int setup_ima_buffer(const struct kimage *image, void 
> *fdt, int chosen_node)
>   if (ret < 0)
>   return -EINVAL;
>  
> - ret = fdt_add_mem_rsv(fdt, image->arch.ima_buffer_addr,
> -   image->arch.ima_buffer_size);
> + ret = fdt_add_mem_rsv(fdt, image->ima_buffer_addr,
> +   image->ima_buffer_size);
>   if (ret)
>   return -EINVAL;
>  
>   pr_debug("IMA buffer at 0x%llx, size = 0x%zx\n",
> -  image->arch.ima_buffer_addr, image->arch.ima_buffer_size);
> +  image->ima_buffer_addr, image->ima_buffer_size);
>  
>   return 0;
>  }
> 

Re: [PATCH v17 00/10] Carry forward IMA measurement log on kexec on ARM64

2021-02-10 Thread Rob Herring
On Tue, Feb 09, 2021 at 10:21:50AM -0800, Lakshmi Ramasubramanian wrote:
> On kexec file load Integrity Measurement Architecture (IMA) subsystem
> may verify the IMA signature of the kernel and initramfs, and measure
> it.  The command line parameters passed to the kernel in the kexec call
> may also be measured by IMA.  A remote attestation service can verify
> a TPM quote based on the TPM event log, the IMA measurement list, and
> the TPM PCR data.  This can be achieved only if the IMA measurement log
> is carried over from the current kernel to the next kernel across
> the kexec call.
> 
> powerpc already supports carrying forward the IMA measurement log on
> kexec.  This patch set adds support for carrying forward the IMA
> measurement log on kexec on ARM64.
> 
> This patch set moves the platform independent code defined for powerpc
> such that it can be reused for other platforms as well.  A chosen node
> "linux,ima-kexec-buffer" is added to the DTB for ARM64 to hold
> the address and the size of the memory reserved to carry
> the IMA measurement log.
> 
> This patch set has been tested for ARM64 platform using QEMU.
> I would like help from the community for testing this change on powerpc.
> Thanks.
> 
> This patch set is based on
> commit 96acc833dec8 ("ima: Free IMA measurement buffer after kexec syscall")
> in https://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git
> "next-integrity" branch.

Is that a hard dependency still? Given this is now almost entirely 
deleting arch code and adding drivers/of/ code, I was going to apply it.

Rob


Declaring unrecoverable_exception() as __noreturn ?

2021-02-10 Thread Christophe Leroy

As far as I can see, almost all callers of unrecoverable_exception() expect it 
to never return.

Can we mark it __noreturn ?

Below is interrupt_exit_kernel_prepare() with then without unrecoverable_exception() declared as 
__noreturn. (CONFIG_PREEMPT_NONE, and with the BUG_ON() removed)


With the __noreturn added, we get no stack frame on the likely path

03a8 :
 3a8:   81 43 00 84 lwz r10,132(r3)
 3ac:   71 4a 00 02 andi.   r10,r10,2
 3b0:   41 82 00 30 beq 3e0 
 3b4:   80 62 00 70 lwz r3,112(r2)
 3b8:   74 63 00 01 andis.  r3,r3,1
 3bc:   40 82 00 34 bne 3f0 
 3c0:   7d 40 00 a6 mfmsr   r10
 3c4:   55 4a 04 5e rlwinm  r10,r10,0,17,15
 3c8:   7d 40 01 24 mtmsr   r10
 3cc:   7d 20 00 a6 mfmsr   r9
 3d0:   55 29 07 fa rlwinm  r9,r9,0,31,29
 3d4:   55 29 04 5e rlwinm  r9,r9,0,17,15
 3d8:   7d 20 01 24 mtmsr   r9
 3dc:   4e 80 00 20 blr
 3e0:   94 21 ff f0 stwur1,-16(r1)
 3e4:   7c 08 02 a6 mflrr0
 3e8:   90 01 00 14 stw r0,20(r1)
 3ec:   48 00 00 01 bl  3ec 
3ec: R_PPC_REL24unrecoverable_exception
 3f0:   38 e2 00 70 addir7,r2,112
 3f4:   3d 00 00 01 lis r8,1
 3f8:   7c c0 38 28 lwarx   r6,0,r7
 3fc:   7c c6 40 78 andcr6,r6,r8
 400:   7c c0 39 2d stwcx.  r6,0,r7
 404:   40 a2 ff f4 bne 3f8 
 408:   38 60 00 01 li  r3,1
 40c:   4b ff ff b4 b   3c0 

Without the modification:

03a8 :
 3a8:   94 21 ff f0 stwur1,-16(r1)
 3ac:   93 e1 00 0c stw r31,12(r1)
 3b0:   81 23 00 84 lwz r9,132(r3)
 3b4:   71 29 00 02 andi.   r9,r9,2
 3b8:   41 82 00 38 beq 3f0 
 3bc:   81 22 00 70 lwz r9,112(r2)
 3c0:   75 23 00 01 andis.  r3,r9,1
 3c4:   40 82 00 4c bne 410 
 3c8:   7d 20 00 a6 mfmsr   r9
 3cc:   55 29 04 5e rlwinm  r9,r9,0,17,15
 3d0:   7d 20 01 24 mtmsr   r9
 3d4:   7d 20 00 a6 mfmsr   r9
 3d8:   55 29 07 fa rlwinm  r9,r9,0,31,29
 3dc:   55 29 04 5e rlwinm  r9,r9,0,17,15
 3e0:   7d 20 01 24 mtmsr   r9
 3e4:   83 e1 00 0c lwz r31,12(r1)
 3e8:   38 21 00 10 addir1,r1,16
 3ec:   4e 80 00 20 blr
 3f0:   7c 08 02 a6 mflrr0
 3f4:   90 01 00 14 stw r0,20(r1)
 3f8:   48 00 00 01 bl  3f8 
3f8: R_PPC_REL24unrecoverable_exception
 3fc:   81 22 00 70 lwz r9,112(r2)
 400:   80 01 00 14 lwz r0,20(r1)
 404:   75 23 00 01 andis.  r3,r9,1
 408:   7c 08 03 a6 mtlrr0
 40c:   41 82 ff bc beq 3c8 
 410:   39 02 00 70 addir8,r2,112
 414:   3d 20 00 01 lis r9,1
 418:   7c e0 40 28 lwarx   r7,0,r8
 41c:   7c e7 48 78 andcr7,r7,r9
 420:   7c e0 41 2d stwcx.  r7,0,r8
 424:   40 a2 ff f4 bne 418 
 428:   38 60 00 01 li  r3,1
 42c:   7d 20 00 a6 mfmsr   r9
 430:   55 29 04 5e rlwinm  r9,r9,0,17,15
 434:   7d 20 01 24 mtmsr   r9
 438:   7d 20 00 a6 mfmsr   r9
 43c:   55 29 07 fa rlwinm  r9,r9,0,31,29
 440:   55 29 04 5e rlwinm  r9,r9,0,17,15
 444:   7d 20 01 24 mtmsr   r9
 448:   83 e1 00 0c lwz r31,12(r1)
 44c:   38 21 00 10 addir1,r1,16
 450:   4e 80 00 20 blr


[PATCH 3/3] powerpc/amigaone: Make amigaone_discover_phbs() static

2021-02-10 Thread Michael Ellerman
It's only used in setup.c, so make it static.

Reported-by: kernel test robot 
Fixes: 053d58c87029 ("powerpc/amigaone: Move PHB discovery")
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/amigaone/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/amigaone/setup.c 
b/arch/powerpc/platforms/amigaone/setup.c
index b25ddf39dd43..9d252c554f7f 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -70,7 +70,7 @@ void __init amigaone_setup_arch(void)
ppc_md.progress("Linux/PPC "UTS_RELEASE"\n", 0);
 }
 
-void __init amigaone_discover_phbs(void)
+static void __init amigaone_discover_phbs(void)
 {
struct device_node *np;
int phb = -ENODEV;
-- 
2.25.1



[PATCH 2/3] powerpc/mm/64s: Fix no previous prototype warning

2021-02-10 Thread Michael Ellerman
As reported by lkp:

  arch/powerpc/mm/book3s64/radix_tlb.c:646:6: warning: no previous
  prototype for function 'exit_lazy_flush_tlb'

Fix it by moving the prototype into the existing header.

Fixes: 032b7f08932c ("powerpc/64s/radix: serialize_against_pte_lookup IPIs trim 
mm_cpumask")
Reported-by: kernel test robot 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/mm/book3s64/internal.h  | 2 ++
 arch/powerpc/mm/book3s64/pgtable.c   | 4 ++--
 arch/powerpc/mm/book3s64/radix_tlb.c | 2 ++
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/internal.h 
b/arch/powerpc/mm/book3s64/internal.h
index c12d78ee42f5..5045048ce244 100644
--- a/arch/powerpc/mm/book3s64/internal.h
+++ b/arch/powerpc/mm/book3s64/internal.h
@@ -15,4 +15,6 @@ static inline bool stress_slb(void)
 
 void slb_setup_new_exec(void);
 
+void exit_lazy_flush_tlb(struct mm_struct *mm, bool always_flush);
+
 #endif /* ARCH_POWERPC_MM_BOOK3S64_INTERNAL_H */
diff --git a/arch/powerpc/mm/book3s64/pgtable.c 
b/arch/powerpc/mm/book3s64/pgtable.c
index 78c492e86752..9ffa65074cb0 100644
--- a/arch/powerpc/mm/book3s64/pgtable.c
+++ b/arch/powerpc/mm/book3s64/pgtable.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 unsigned long __pmd_frag_nr;
 EXPORT_SYMBOL(__pmd_frag_nr);
 unsigned long __pmd_frag_size_shift;
@@ -79,8 +81,6 @@ void set_pmd_at(struct mm_struct *mm, unsigned long addr,
return set_pte_at(mm, addr, pmdp_ptep(pmdp), pmd_pte(pmd));
 }
 
-void exit_lazy_flush_tlb(struct mm_struct *mm, bool always_flush);
-
 static void do_serialize(void *arg)
 {
/* We've taken the IPI, so try to trim the mask while here */
diff --git a/arch/powerpc/mm/book3s64/radix_tlb.c 
b/arch/powerpc/mm/book3s64/radix_tlb.c
index d7f1a6bd08ef..409e61210789 100644
--- a/arch/powerpc/mm/book3s64/radix_tlb.c
+++ b/arch/powerpc/mm/book3s64/radix_tlb.c
@@ -18,6 +18,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 #define RIC_FLUSH_TLB 0
 #define RIC_FLUSH_PWC 1
 #define RIC_FLUSH_ALL 2
-- 
2.25.1



[PATCH 1/3] powerpc/83xx: Fix build error when CONFIG_PCI=n

2021-02-10 Thread Michael Ellerman
As reported by lkp:

  arch/powerpc/platforms/83xx/km83xx.c:183:19: error: 'mpc83xx_setup_pci' 
undeclared here (not in a function)
 183 |  .discover_phbs = mpc83xx_setup_pci,
 |   ^
 |   mpc83xx_setup_arch

There is a stub defined for the CONFIG_PCI=n case, but now that
mpc83xx_setup_pci() is being assigned to discover_phbs the correct
empty value is NULL.

Fixes: 83f84041ff1c ("powerpc/83xx: Move PHB discovery")
Reported-by: kernel test robot 
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/platforms/83xx/mpc83xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h 
b/arch/powerpc/platforms/83xx/mpc83xx.h
index f37d04332fc7..a30d30588cf6 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -76,7 +76,7 @@ extern void mpc83xx_ipic_init_IRQ(void);
 #ifdef CONFIG_PCI
 extern void mpc83xx_setup_pci(void);
 #else
-#define mpc83xx_setup_pci()do {} while (0)
+#define mpc83xx_setup_pci  NULL
 #endif
 
 extern int mpc83xx_declare_of_platform_devices(void);
-- 
2.25.1



Re: [PATCH v3] powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mm

2021-02-10 Thread Michael Ellerman
On Sat, 6 Feb 2021 08:26:34 +0530, Aneesh Kumar K.V wrote:
> This fix the bad fault reported by KUAP when io_wqe_worker access userspace.
> 
>  Bug: Read fault blocked by KUAP!
>  WARNING: CPU: 1 PID: 101841 at arch/powerpc/mm/fault.c:229 
> __do_page_fault+0x6b4/0xcd0
>  NIP [c009e7e4] __do_page_fault+0x6b4/0xcd0
>  LR [c009e7e0] __do_page_fault+0x6b0/0xcd0
> ..
>  Call Trace:
>  [c00016367330] [c009e7e0] __do_page_fault+0x6b0/0xcd0 
> (unreliable)
>  [c000163673e0] [c009ee3c] do_page_fault+0x3c/0x120
>  [c00016367430] [c000c848] handle_page_fault+0x10/0x2c
>  --- interrupt: 300 at iov_iter_fault_in_readable+0x148/0x6f0
> ..
>  NIP [c08e8228] iov_iter_fault_in_readable+0x148/0x6f0
>  LR [c08e834c] iov_iter_fault_in_readable+0x26c/0x6f0
>  interrupt: 300
>  [c000163677e0] [c07154a0] iomap_write_actor+0xc0/0x280
>  [c00016367880] [c070fc94] iomap_apply+0x1c4/0x780
>  [c00016367990] [c0710330] iomap_file_buffered_write+0xa0/0x120
>  [c000163679e0] [c0080040791c] 
> xfs_file_buffered_aio_write+0x314/0x5e0 [xfs]
>  [c00016367a90] [c06d74bc] io_write+0x10c/0x460
>  [c00016367bb0] [c06d80e4] io_issue_sqe+0x8d4/0x1200
>  [c00016367c70] [c06d8ad0] io_wq_submit_work+0xc0/0x250
>  [c00016367cb0] [c06e2578] io_worker_handle_work+0x498/0x800
>  [c00016367d40] [c06e2cdc] io_wqe_worker+0x3fc/0x4f0
>  [c00016367da0] [c01cb0a4] kthread+0x1c4/0x1d0
>  [c00016367e10] [c000dbf0] ret_from_kernel_thread+0x5c/0x6c
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mm
  https://git.kernel.org/powerpc/c/8c511eff1827239f24ded212b1bcda7ca5b16203

cheers


Re: [PATCH] arch: powerpc: kernel: Fix the spelling mismach to mismatch in head.44x.S

2021-02-10 Thread Michael Ellerman
On Tue, 2 Feb 2021 15:07:46 +0530, Bhaskar Chowdhury wrote:
> s/mismach/mismatch/

Applied to powerpc/next.

[1/1] powerpc/44x: Fix a spelling mismach to mismatch in head_44x.S
  https://git.kernel.org/powerpc/c/ea7826583f5ed7abca97e6e56441caadcbbd957a

cheers


Re: [PATCH v4 1/2] powerpc: sstep: Fix load-store and update emulation

2021-02-10 Thread Michael Ellerman
On Thu, 4 Feb 2021 13:37:43 +0530, Sandipan Das wrote:
> The Power ISA says that the fixed-point load and update
> instructions must neither use R0 for the base address (RA)
> nor have the destination (RT) and the base address (RA) as
> the same register. Similarly, for fixed-point stores and
> floating-point loads and stores, the instruction is invalid
> when R0 is used as the base address (RA).
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/sstep: Fix load-store and update emulation
  https://git.kernel.org/powerpc/c/bbda4b6c7d7c7f79da71f95c92a5d76be22c3efd
[2/2] powerpc/sstep: Fix darn emulation
  https://git.kernel.org/powerpc/c/22b89ba178dd0a66a26699ead014a3e73ff8e044

cheers


Re: [PATCH] powerpc/pkeys: Remove unused code

2021-02-10 Thread Michael Ellerman
On Tue, 2 Feb 2021 20:30:50 +0530, Sandipan Das wrote:
> This removes arch_supports_pkeys(), arch_usable_pkeys() and
> thread_pkey_regs_*() which are remnants from the following:
> 
> commit 06bb53b33804 ("powerpc: store and restore the pkey state across 
> context switches")
> commit 2cd4bd192ee9 ("powerpc/pkeys: Fix handling of pkey state across 
> fork()")
> commit cf43d3b26452 ("powerpc: Enable pkey subsystem")
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pkeys: Remove unused code
  https://git.kernel.org/powerpc/c/266d8f7586533a4c473ccb392204e32df99b72b5

cheers


Re: [PATCH v2] powerpc/powernv/pci: Drop pnv_phb->initialized

2021-02-10 Thread Michael Ellerman
On Wed, 2 Sep 2020 11:36:57 +1000, Oliver O'Halloran wrote:
> The pnv_phb->initialized flag is an odd beast. It was added back in 2012 in
> commit db1266c85261 ("powerpc/powernv: Skip check on PE if necessary") to
> allow devices to be enabled even if the device had not yet been assigned to
> a PE. Allowing the device to be enabled before the PE is configured may
> cause spurious EEH events since none of the IOMMU context has been setup.
> 
> I'm not entirely sure why this was ever necessary. My best guess is that it
> was an workaround for a bug or some other undesireable behaviour from the
> PCI core. Either way, it's unnecessary now since as of commit dc3d8f85bb57
> ("powerpc/powernv/pci: Re-work bus PE configuration") we can guarantee that
> the PE will be configured before the PCI core will allow drivers to bind to
> the device.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/powernv/pci: Drop pnv_phb->initialized
  https://git.kernel.org/powerpc/c/24b4c6b1a7fc79fe8142d50cb439944b81b659ff

cheers


Re: [PATCH 01/18] powerpc/pci: Add ppc_md.discover_phbs()

2021-02-10 Thread Michael Ellerman
On Tue, 3 Nov 2020 15:35:06 +1100, Oliver O'Halloran wrote:
> On many powerpc platforms the discovery and initalisation of
> pci_controllers (PHBs) happens inside of setup_arch(). This is very early
> in boot (pre-initcalls) and means that we're initialising the PHB long
> before many basic kernel services (slab allocator, debugfs, a real ioremap)
> are available.
> 
> On PowerNV this causes an additional problem since we map the PHB registers
> with ioremap(). As of commit d538aadc2718 ("powerpc/ioremap: warn on early
> use of ioremap()") a warning is printed because we're using the "incorrect"
> API to setup and MMIO mapping in searly boot. The kernel does provide
> early_ioremap(), but that is not intended to create long-lived MMIO
> mappings and a seperate warning is printed by generic code if
> early_ioremap() mappings are "leaked."
> 
> [...]

Applied to powerpc/next.

[01/18] powerpc/pci: Add ppc_md.discover_phbs()

https://git.kernel.org/powerpc/c/5537fcb319d016ce387f818dd774179bc03217f5
[02/18] powerpc/pci: Move PHB discovery for PCI_DN using platforms

https://git.kernel.org/powerpc/c/fbbefb320214db14c3e740fce98e2c95c9d0669b
[03/18] powerpc/maple: Move PHB discovery
(squashed into 2)
[04/18] powerpc/512x: Move PHB discovery

https://git.kernel.org/powerpc/c/893586ec949d3e48573a585c26bf04998fea6e1f
[05/18] powerpc/52xx/efika: Move PHB discovery

https://git.kernel.org/powerpc/c/eab3166f4eac384b48ebd2ed7b61dc465c1912cf
[06/18] powerpc/52xx/lite5200: Move PHB discovery

https://git.kernel.org/powerpc/c/e0bf9de2242a31a8f79015376ed08c4efe74774a
[07/18] powerpc/52xx/media5200: Move PHB discovery

https://git.kernel.org/powerpc/c/ba5087622a0f11c8d3c6587392ebc70f96503e51
[08/18] powerpc/52xx/mpc5200_simple: Move PHB discovery

https://git.kernel.org/powerpc/c/a760cfd9cfa2193961d7e599f46fbfe2498c400a
[09/18] powerpc/82xx/*: Move PHB discovery

https://git.kernel.org/powerpc/c/3c82a6aecd367bbbe7876c406cd3e12b5b0e4204
[10/18] powerpc/83xx: Move PHB discovery

https://git.kernel.org/powerpc/c/83f84041ff1cf6c23fc38861218af2d4ca2d9b38
[11/18] powerpc/amigaone: Move PHB discovery

https://git.kernel.org/powerpc/c/053d58c870298d62b9c5154672ef2f1684c4ea43
[12/18] powerpc/chrp: Move PHB discovery

https://git.kernel.org/powerpc/c/407d418f2fd4c20aa8ca1cf4168a414d77766852
[13/18] powerpc/embedded6xx/holly: Move PHB discovery

https://git.kernel.org/powerpc/c/08c4738254b87117c69816d8033dd25f38185f92
[14/18] powerpc/embedded6xx/linkstation: Move PHB discovery

https://git.kernel.org/powerpc/c/daa6c24780c15f4abcb76a9d426142beff9f62c6
[15/18] powerpc/embedded6xx/mpc7448: Move PHB discovery

https://git.kernel.org/powerpc/c/748770aeb44108ecb4e09d273e7718611cd60a98
[16/18] powerpc/embedded6xx/mve5100: Move PHB discovery

https://git.kernel.org/powerpc/c/d20a864f434b277b245ac6508920d90a48f6155d
[17/18] powerpc/pasemi: Move PHB discovery

https://git.kernel.org/powerpc/c/c144bc719234500e292c0545de99822bd8a78a6b
[18/18] powerpc/powermac: Move PHB discovery
(squashed into 2)

cheers


Re: [PATCH v7 00/42] powerpc: interrupt wrappers

2021-02-10 Thread Michael Ellerman
On Sat, 30 Jan 2021 23:08:10 +1000, Nicholas Piggin wrote:
> This adds interrupt handler wrapper functions, similar to the
> generic / x86 code, and moves several common operations into them
> from either asm or open coded in the individual handlers.
> 
> This series is based on powerpc fixes-test tree, there's another
> unrelated pending fix in patch 1 of the series which clashes a
> bit.
> 
> [...]

Patches 1-41 applied to powerpc/next.

[01/42] powerpc/64s: interrupt exit improve bounding of interrupt recursion

https://git.kernel.org/powerpc/c/c0ef717305f51e29b5ce0c78a6bfe566b3283415
[02/42] KVM: PPC: Book3S HV: Context tracking exit guest context before 
enabling irqs

https://git.kernel.org/powerpc/c/112665286d08c87e66d699e7cba43c1497ad165f
[03/42] powerpc/32s: move DABR match out of handle_page_fault

https://git.kernel.org/powerpc/c/7a24ae2e172f770df07f8e48ed3ed2f3a6b17e37
[04/42] powerpc/64s: move DABR match out of handle_page_fault

https://git.kernel.org/powerpc/c/36f0114140eef53e931592b65bdf8bb61ffac1f8
[05/42] powerpc/64s: move the hash fault handling logic to C

https://git.kernel.org/powerpc/c/a4922f5442e7e6ce85da304e224d940edec2f1fb
[06/42] powerpc: remove arguments from fault handler functions

https://git.kernel.org/powerpc/c/a01a3f2ddbcda83e8572787c0ec1dcbeba86915a
[07/42] powerpc/fsl_booke/32: CacheLockingException remove args

https://git.kernel.org/powerpc/c/b4ced8031000b832d845dd17994e0fa1b8310496
[08/42] powerpc: do_break get registers from regs

https://git.kernel.org/powerpc/c/18722ecf9efdc6a7ca933a3e5a83cc9dba375847
[09/42] powerpc: DebugException remove args

https://git.kernel.org/powerpc/c/755d664174463791489dddf34c33308b61de68c3
[10/42] powerpc/32: transfer can avoid saving r4/r5 over trace call

https://git.kernel.org/powerpc/c/73d7a97914f23397b012e851f6a1fe4061923a82
[11/42] powerpc: bad_page_fault get registers from regs

https://git.kernel.org/powerpc/c/8458c628a53ba4311b2df12370be1a6f1870ff37
[12/42] powerpc/64s: add do_bad_page_fault_segv handler

https://git.kernel.org/powerpc/c/71f47976fafc4375674bd0714153be10f878040a
[13/42] powerpc: rearrange do_page_fault error case to be inside exception_enter

https://git.kernel.org/powerpc/c/4cb8428465148bcca0b6b8593d51f805818a70e0
[14/42] powerpc/64s: move bad_page_fault handling to C

https://git.kernel.org/powerpc/c/f4c03b0e520c5f56e569a8da3fce5ddbd0696742
[15/42] powerpc/64s: split do_hash_fault

https://git.kernel.org/powerpc/c/bf0e2374aa7b4f8b01fd59fcb0746a9b6b05326a
[16/42] powerpc/mm: Remove stale do_page_fault comment referring to SLB faults

https://git.kernel.org/powerpc/c/31d6490ccb2868530300381d8079026cd4a9f7ad
[17/42] powerpc/64s: slb comment update

https://git.kernel.org/powerpc/c/e44370abb2e99299678ec6b209f8aad574fa5f36
[18/42] powerpc/traps: add NOKPROBE_SYMBOL for sreset and mce

https://git.kernel.org/powerpc/c/3a3138836bc35966d59742512b597997755878f7
[19/42] powerpc/perf: move perf irq/nmi handling details into traps.c

https://git.kernel.org/powerpc/c/156b5371a9c2482a9ad23ec82d1a4f89a3ab430d
[20/42] powerpc/time: move timer_broadcast_interrupt prototype to asm/time.h

https://git.kernel.org/powerpc/c/0440b8a22cc48922f7c6ae894abd221cf7cc4b64
[21/42] powerpc: add and use unknown_async_exception

https://git.kernel.org/powerpc/c/6c6aee009ec34cb7f5ef76f910c1b9417c81efd8
[22/42] powerpc/cell: tidy up pervasive declarations

https://git.kernel.org/powerpc/c/dcdb4f12963f3f4200e24e1dad78564a98736f67
[23/42] powerpc: introduce die_mce

https://git.kernel.org/powerpc/c/209e9d500e25eada096b2c09a34093bc458166f3
[24/42] powerpc/mce: ensure machine check handler always tests RI

https://git.kernel.org/powerpc/c/c538938fa2cfdc806c6304888e3876729e6939e0
[25/42] powerpc: improve handling of unrecoverable system reset

https://git.kernel.org/powerpc/c/11cb0a25f71818ca7ab4856548ecfd83c169aa4d
[26/42] powerpc: interrupt handler wrapper functions

https://git.kernel.org/powerpc/c/8d41fc618ab804657acd2df8e761ce1001f41513
[27/42] powerpc: add interrupt wrapper entry / exit stub functions

https://git.kernel.org/powerpc/c/25b7e6bb743ca5a375bb89522a2c2bec840d5fc3
[28/42] powerpc: convert interrupt handlers to use wrappers

https://git.kernel.org/powerpc/c/3a96570ffceb15c6ed9cc6f990f172dcdc8ac279
[29/42] powerpc: add interrupt_cond_local_irq_enable helper

https://git.kernel.org/powerpc/c/e6f8a6c86ce7b2108c03c1cc014fdae278573df1
[30/42] powerpc/64: context tracking remove _TIF_NOHZ

https://git.kernel.org/powerpc/c/2a06bf3e95cd93e3640d431960181b8e47415f33
[31/42] powerpc/64s/hash: improve context tracking of hash faults

https://git.kernel.org/powerpc/c/a008f8f9fd67ffb13d906ef4ea6235a3d62dfdb6
[32/42] powerpc/64: context tracking move to interrupt wrappers


Re: [PATCH 0/7] powerpc/64s: TLB flushing improvements

2021-02-10 Thread Michael Ellerman
On Thu, 17 Dec 2020 23:47:24 +1000, Nicholas Piggin wrote:
> Another round of reducing TLB flushing (mostly on radix).
> 
> Thanks,
> Nick
> 
> Nicholas Piggin (7):
>   powerpc/64s/radix: add warning and comments in mm_cpumask trim
>   powerpc/64s/radix: refactor TLB flush type selection
>   powerpc/64s/radix: Check for no TLB flush required
>   powerpc/64s/radix: Allow mm_cpumask trimming from external sources
>   powerpc/64s/radix: occasionally attempt to trim mm_cpumask
>   powerpc/64s/radix: serialize_against_pte_lookup IPIs trim mm_cpumask
>   powerpc/64s: Implement ptep_clear_flush_young that does not flush TLBs
> 
> [...]

Applied to powerpc/next.

[1/7] powerpc/64s/radix: add warning and comments in mm_cpumask trim
  https://git.kernel.org/powerpc/c/a2496049f1f1006178d0db706a8451dd03bd3ec6
[2/7] powerpc/64s/radix: refactor TLB flush type selection
  https://git.kernel.org/powerpc/c/26418b36a11f2eaf2556aa8cefe86132907e311f
[3/7] powerpc/64s/radix: Check for no TLB flush required
  https://git.kernel.org/powerpc/c/54bb503345b81399575e2b7a3a6497ae212ad827
[4/7] powerpc/64s/radix: Allow mm_cpumask trimming from external sources
  https://git.kernel.org/powerpc/c/780de40601aabeca41bc9aa717a329a77aa85e1a
[5/7] powerpc/64s/radix: occasionally attempt to trim mm_cpumask
  https://git.kernel.org/powerpc/c/9393544842d6c85ebfc387c43a5059f8171d598f
[6/7] powerpc/64s/radix: serialize_against_pte_lookup IPIs trim mm_cpumask
  https://git.kernel.org/powerpc/c/032b7f08932c9b212952d6d585e45b2941b3e8be
[7/7] powerpc/64s: Implement ptep_clear_flush_young that does not flush TLBs
  https://git.kernel.org/powerpc/c/3cb1aa7aa39402f4f2cb847b1f16ade3bce43a97

cheers


Re: [PATCH] powerpc/pseries/dlpar: handle ibm, configure-connector delay status

2021-02-10 Thread Michael Ellerman
On Wed, 6 Jan 2021 20:59:00 -0600, Nathan Lynch wrote:
> dlpar_configure_connector() has two problems in its handling of
> ibm,configure-connector's return status:
> 
> 1. When the status is -2 (busy, call again), we call
>ibm,configure-connector again immediately without checking whether
>to schedule, which can result in monopolizing the CPU.
> 2. Extended delay status (9900..9905) goes completely unhandled,
>causing the configuration to unnecessarily terminate.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pseries/dlpar: handle ibm, configure-connector delay status
  https://git.kernel.org/powerpc/c/768d70e19ba525debd571b36e6d0ab19956c63d7

cheers


Re: [PATCH] powerpc/akebono: Fix unmet dependency errors

2021-02-10 Thread Michael Ellerman
On Mon, 1 Feb 2021 12:25:03 +1100, Michael Ellerman wrote:
> The AKEBONO config has various selects under it, including some with
> user-selectable dependencies, which means those dependencies can be
> disabled. This leads to warnings from Kconfig.
> 
> This can be seen with eg:
> 
>   $ make allnoconfig
>   $ ./scripts/config --file build~/.config -k -e CONFIG_44x -k -e 
> CONFIG_PPC_47x -e CONFIG_AKEBONO
>   $ make olddefconfig
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/akebono: Fix unmet dependency errors
  https://git.kernel.org/powerpc/c/665d8d58761cba41147fe7e98e2ceed1cbf603a2

cheers


Re: [PATCH 1/2] powerpc/64: Make stack tracing work during very early boot

2021-02-10 Thread Michael Ellerman
On Wed, 3 Feb 2021 00:02:06 +1100, Michael Ellerman wrote:
> If we try to stack trace very early during boot, either due to a
> WARN/BUG or manual dump_stack(), we will oops in
> valid_emergency_stack() when we try to dereference the paca_ptrs
> array.
> 
> The fix is simple, we just return false if paca_ptrs isn't allocated
> yet. The stack pointer definitely isn't part of any emergency stack
> because we haven't allocated any yet.

Applied to powerpc/next.

[1/2] powerpc/64: Make stack tracing work during very early boot
  https://git.kernel.org/powerpc/c/0ecf6a9e47d825b7dddfebca738386b809e59a94
[2/2] powerpc/64s: Handle program checks in wrong endian during early boot
  https://git.kernel.org/powerpc/c/e7eb919057c3450cdd9d335e4a23a4da8da58db4

cheers


Re: [PATCH] powerpc: remove unneeded semicolons

2021-02-10 Thread Michael Ellerman
On Mon, 25 Jan 2021 17:53:38 +0800, Chengyang Fan wrote:
> Remove superfluous semicolons after function definitions.

Applied to powerpc/next.

[1/1] powerpc: remove unneeded semicolons
  https://git.kernel.org/powerpc/c/6c6fdbb2b7002aa04e418b5d2b26df1c5ba5ab80

cheers


Re: [PATCH v2] powerpc64/idle: Fix SP offsets when saving GPRs

2021-02-10 Thread Michael Ellerman
On Sat, 6 Feb 2021 01:23:42 -0600, Christopher M. Riedl wrote:
> The idle entry/exit code saves/restores GPRs in the stack "red zone"
> (Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
> used for the first GPR is incorrect and overwrites the back chain - the
> Protected Zone actually starts below the current SP. In practice this is
> probably not an issue, but it's still incorrect so fix it.
> 
> Also expand the comments to explain why using the stack "red zone"
> instead of creating a new stackframe is appropriate here.

Applied to powerpc/next.

[1/1] powerpc64/idle: Fix SP offsets when saving GPRs
  https://git.kernel.org/powerpc/c/73287caa9210ded6066833195f4335f7f688a46b

cheers


Re: [PATCH] powerpc/uaccess: Perform barrier_nospec() in KUAP allowance helpers

2021-02-10 Thread Michael Ellerman
On Sun, 7 Feb 2021 10:08:11 + (UTC), Christophe Leroy wrote:
> barrier_nospec() in uaccess helpers is there to protect against
> speculative accesses around access_ok().
> 
> When using user_access_begin() sequences together with
> unsafe_get_user() like macros, barrier_nospec() is called for
> every single read although we know the access_ok() is done
> onece.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/uaccess: Perform barrier_nospec() in KUAP allowance helpers
  https://git.kernel.org/powerpc/c/8524e2e76441fc615a3b5c1415823e051cc79eae

cheers


Re: [PATCH V2] powerpc/perf: Record counter overflow always if SAMPLE_IP is unset

2021-02-10 Thread Michael Ellerman
On Fri, 5 Feb 2021 04:14:52 -0500, Athira Rajeev wrote:
> While sampling for marked events, currently we record the sample only
> if the SIAR valid bit of Sampled Instruction Event Register (SIER) is
> set. SIAR_VALID bit is used for fetching the instruction address from
> Sampled Instruction Address Register(SIAR). But there are some usecases,
> where the user is interested only in the PMU stats at each counter
> overflow and the exact IP of the overflow event is not required.
> Dropping SIAR invalid samples will fail to record some of the counter
> overflows in such cases.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/perf: Record counter overflow always if SAMPLE_IP is unset
  https://git.kernel.org/powerpc/c/d137845c973147a22622cc76c7b0bc16f6206323

cheers


Re: [PATCH] powerpc/8xx: Fix software emulation interrupt

2021-02-10 Thread Michael Ellerman
On Fri, 5 Feb 2021 08:56:13 + (UTC), Christophe Leroy wrote:
> For unimplemented instructions or unimplemented SPRs, the 8xx triggers
> a "Software Emulation Exception" (0x1000). That interrupt doesn't set
> reason bits in SRR1 as the "Program Check Exception" does.
> 
> Go through emulation_assist_interrupt() to set REASON_ILLEGAL.

Applied to powerpc/next.

[1/1] powerpc/8xx: Fix software emulation interrupt
  https://git.kernel.org/powerpc/c/903178d0ce6bb30ef80a3604ab9ee2b57869fbc9

cheers


Re: [PATCH 1/3] powerpc/32s: Change mfsrin() into a static inline function

2021-02-10 Thread Michael Ellerman
On Sat, 6 Feb 2021 11:47:26 + (UTC), Christophe Leroy wrote:
> mfsrin() is a macro.
> 
> Change in into an inline function to avoid conflicts in KVM
> and make it more evolutive.

Applied to powerpc/next.

[1/3] powerpc/32s: Change mfsrin() into a static inline function
  https://git.kernel.org/powerpc/c/fd659e8f2c6d1e1e96fd5bdb515518801cd02012
[2/3] powerpc/32s: mfsrin()/mtsrin() become mfsr()/mtsr()
  https://git.kernel.org/powerpc/c/179ae57dbad1b9a83eec376aa44d54fc24352e37
[3/3] powerpc/32s: Allow constant folding in mtsr()/mfsr()
  https://git.kernel.org/powerpc/c/b842d131c7983f8f0b9c9572c073130b5f2bcf11

cheers


Re: [PATCH 0/3] powerpc/perf: Add Performance Monitor Counters to extended regs

2021-02-10 Thread Michael Ellerman
On Wed, 3 Feb 2021 01:55:34 -0500, Athira Rajeev wrote:
> Patch set to add Performance Monitor Counter SPR's as
> part of extended regs in powerpc.
> 
> Patch 1/3 saves the PMC values in the perf interrupt
> handler as part of per-cpu array.
> Patch 2/3 adds PMC1 to PMC6 as part of the extended
> regs mask.
> Patch 3/3 includes perf tools side changes to add
> PMC1 to PMC6 to sample_reg_mask to use with -I? option.
> 
> [...]

Patches 1 & 2 applied to powerpc/next.

[1/3] powerpc/perf: Include PMCs as part of per-cpu cpuhw_events struct
  https://git.kernel.org/powerpc/c/91f3469a43fd1fb831649c2a2e684bf5ad4818b2
[2/3] powerpc/perf: Expose Performance Monitor Counter SPR's as part of 
extended regs
  https://git.kernel.org/powerpc/c/e79b76e03b712e42c58d9649c92571e346abc38b

cheers


Re: [PATCH] selftests/powerpc: Fix L1D flushing tests for Power10

2021-02-10 Thread Michael Ellerman
Russell Currey  writes:
> The rfi_flush and entry_flush selftests work by using the PM_LD_MISS_L1
> perf event to count L1D misses.  The value of this event has changed
> over time:
>
> - Power7 uses 0x400f0
> - Power8 and Power9 use both 0x400f0 and 0x3e054
> - Power10 uses only 0x3e054
>
> Update these selftests to use the value 0x3e054 on P10 and later,
> fixing the tests from finding 0 events.

I wonder if we can just use the cache events that the kernel knows
about.

ie, switch the type to PERF_TYPE_HW_CACHE and the event to
PERF_COUNT_HW_CACHE_MISSES.

That would end up using the same event on power7 and power8:

$ git grep PERF_COUNT_HW_CACHE_MISSES arch/powerpc/perf/power{7,8,9,10}*.c
arch/powerpc/perf/power7-pmu.c: [PERF_COUNT_HW_CACHE_MISSES] =  
PM_LD_MISS_L1,
arch/powerpc/perf/power8-pmu.c: [PERF_COUNT_HW_CACHE_MISSES] =  
PM_LD_MISS_L1,
arch/powerpc/perf/power9-pmu.c: [PERF_COUNT_HW_CACHE_MISSES] =  
PM_LD_MISS_L1_FIN,
arch/powerpc/perf/power10-pmu.c:[PERF_COUNT_HW_CACHE_MISSES] =  
PM_LD_MISS_L1,
arch/powerpc/perf/power10-pmu.c:[PERF_COUNT_HW_CACHE_MISSES] =  
PM_LD_DEMAND_MISS_L1_FIN,

On power9 and power10 it's using slightly different events. But I think
it should still work, because these tests just counts misses
with/without the various flushes enabled.

The distinction between loads that miss at execute vs finish shouldn't
matter, but you'd need to test.

The advantage would be we wouldn't then need to update the test again
for future CPUs.

cheers


Re: interrupt_exit_kernel_prepare() on booke/32 has a useless 'mfmsr' and two 'wrteei 0'

2021-02-10 Thread Nicholas Piggin
Excerpts from Christophe Leroy's message of February 10, 2021 7:21 pm:
> 44x/bamboo_defconfig
> 
> For the mfmsr, that's because mfmsr is defined as 'asm volatile'. Is that 
> correct ? Reading MSR 
> doesn't have any side effects as far as I know, should we remove the volatile 
> ?

Well I'm not really sure. It depends on the MSR value, so it must not 
assume it's unchanging.

If you just have asm ("mfmsr %0" : "=r"(msr)) then that's wrong because 
it will omit the second mfmsr in a mfmsr() ; mtmsr() ; mfmsr() sequence.

Adding a "memory" clobber there makes gcc produce the second mfmsr, but 
I don't know if that's really the right thing to do.

> 
> For the wrteei, that's because we are calling __hard_EE_RI_disable() after 
> local_irq_save(). On 
> booke those two fonctions do exactly the same because RI doesn't exist. Could 
> we replace that by a 
> __hard_RI_disable() that would be a nop on booke ?

Not on 64-bit because local_irq_disable() doesn't disable EE there.
You could have something like __hard_EE_RI_disable_irqoff() that is to 
be called only in irq disabled region. But is that just adding too much 
complexity to try to keep 32 and 64 bit unified?

Maybe just making different code paths for 32 and 64 would be best. 
32-bit seems fairly simple

if (!arch_irq_disabled_regs(regs)) {
/* Returning to a kernel context with local irqs enabled. */
WARN_ON_ONCE(!(regs->msr & MSR_EE));

local_irq_disable();
if (IS_ENABLED(CONFIG_PREEMPT)) {
/* Return to preemptible kernel context */
if (unlikely(*ti_flagsp & _TIF_NEED_RESCHED)) {
if (preempt_count() == 0)
preempt_schedule_irq();
}
}
trace_hardirqs_on();
__hard_RI_disable();
} else {
__hard_EE_RI_disable();
}

You could get rid of that entirely if no preempt or irq tracing and just
have __hard_EE_RI_disable even AFAIKS.

Thanks,
Nick


[powerpc:next-test 105/159] arch/powerpc/kernel/syscall_64.c:177:28: error: unused function 'prep_irq_for_enabled_exit'

2021-02-10 Thread kernel test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
next-test
head:   5811244192fc4e18c001c69300044c2acf30bd91
commit: 2a06bf3e95cd93e3640d431960181b8e47415f33 [105/159] powerpc/64: context 
tracking remove _TIF_NOHZ
config: powerpc-randconfig-r022-20210209 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=2a06bf3e95cd93e3640d431960181b8e47415f33
git remote add powerpc 
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
git fetch --no-tags powerpc next-test
git checkout 2a06bf3e95cd93e3640d431960181b8e47415f33
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

>> arch/powerpc/kernel/syscall_64.c:177:28: error: unused function 
>> 'prep_irq_for_enabled_exit' [-Werror,-Wunused-function]
   static notrace inline bool prep_irq_for_enabled_exit(bool clear_ri, bool 
irqs_enabled)
  ^
   1 error generated.


vim +/prep_irq_for_enabled_exit +177 arch/powerpc/kernel/syscall_64.c

   176  
 > 177  static notrace inline bool prep_irq_for_enabled_exit(bool clear_ri, 
 > bool irqs_enabled)
   178  {
   179  if (__prep_irq_for_enabled_exit(clear_ri))
   180  return true;
   181  
   182  /*
   183   * Must replay pending soft-masked interrupts now. Don't just
   184   * local_irq_enabe(); local_irq_disable(); because if we are
   185   * returning from an asynchronous interrupt here, another one
   186   * might hit after irqs are enabled, and it would exit via this
   187   * same path allowing another to fire, and so on unbounded.
   188   *
   189   * If interrupts were enabled when this interrupt exited,
   190   * indicating a process context (synchronous) interrupt,
   191   * local_irq_enable/disable can be used, which will enable
   192   * interrupts rather than keeping them masked (unclear how
   193   * much benefit this is over just replaying for all cases,
   194   * because we immediately disable again, so all we're really
   195   * doing is allowing hard interrupts to execute directly for
   196   * a very small time, rather than being masked and replayed).
   197   */
   198  if (irqs_enabled) {
   199  local_irq_enable();
   200  local_irq_disable();
   201  } else {
   202  replay_soft_interrupts();
   203  }
   204  
   205  return false;
   206  }
   207  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


Re: linux-next: build failure after merge of the powerpc tree

2021-02-10 Thread Stephen Rothwell
Hi Nick,

On Wed, 10 Feb 2021 18:20:54 +1000 Nicholas Piggin  wrote:
>
> Thanks for that, it's due to .noinstr section being put on the other 
> side of .text, so all our interrupt handler asm code can't reach them 
> directly anymore since the ppc interrupt wrappers patch added noinstr
> attribute.
> 
> That's not strictly required though, we've used NOKPROBE_SYMBOL okay
> until now. If you can take this patch for now, it should get 
> allyesconfig to build again. I'll fix it in the powerpc tree before the 
> merge window.
> 
> --
> 
> diff --git a/arch/powerpc/include/asm/interrupt.h 
> b/arch/powerpc/include/asm/interrupt.h
> index 4badb3e51c19..fee1e4dd1e84 100644
> --- a/arch/powerpc/include/asm/interrupt.h
> +++ b/arch/powerpc/include/asm/interrupt.h
> @@ -172,6 +172,8 @@ static inline void interrupt_nmi_exit_prepare(struct 
> pt_regs *regs, struct inter
>  #define DECLARE_INTERRUPT_HANDLER_RAW(func)  \
>   __visible long func(struct pt_regs *regs)
>  
> +#define ppc_noinstr noinline notrace __no_kcsan __no_sanitize_address
> +
>  /**
>   * DEFINE_INTERRUPT_HANDLER_RAW - Define raw interrupt handler function
>   * @func:Function name of the entry point
> @@ -198,7 +200,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
> pt_regs *regs, struct inter
>  #define DEFINE_INTERRUPT_HANDLER_RAW(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   long ret;   \
>   \
> @@ -228,7 +230,7 @@ static __always_inline long ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER(func)   
> \
>  static __always_inline void ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr void func(struct pt_regs *regs)\
> +__visible ppc_noinstr void func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   \
> @@ -262,7 +264,7 @@ static __always_inline void ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_RET(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   long ret;   \
> @@ -297,7 +299,7 @@ static __always_inline long ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_ASYNC(func) \
>  static __always_inline void ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr void func(struct pt_regs *regs)\
> +__visible ppc_noinstr void func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_state state;   \
>   \
> @@ -331,7 +333,7 @@ static __always_inline void ##func(struct pt_regs 
> *regs)
>  #define DEFINE_INTERRUPT_HANDLER_NMI(func)   \
>  static __always_inline long ##func(struct pt_regs *regs);
> \
>   \
> -__visible noinstr long func(struct pt_regs *regs)\
> +__visible ppc_noinstr long func(struct pt_regs *regs)
> \
>  {\
>   struct interrupt_nmi_state state;   \
>   long ret;   \

Tested-by: Stephen Rothwell   # allyesconfig build

-- 
Cheers,
Stephen Rothwell


pgpKQRYuHMgwL.pgp
Description: OpenPGP digital signature


interrupt_exit_kernel_prepare() on booke/32 has a useless 'mfmsr' and two 'wrteei 0'

2021-02-10 Thread Christophe Leroy

44x/bamboo_defconfig

For the mfmsr, that's because mfmsr is defined as 'asm volatile'. Is that correct ? Reading MSR 
doesn't have any side effects as far as I know, should we remove the volatile ?


For the wrteei, that's because we are calling __hard_EE_RI_disable() after local_irq_save(). On 
booke those two fonctions do exactly the same because RI doesn't exist. Could we replace that by a 
__hard_RI_disable() that would be a nop on booke ?



0364 :
 364:   81 23 00 84 lwz r9,132(r3)
 368:   55 29 04 62 rlwinm  r9,r9,0,17,17
 36c:   0f 09 00 00 twnei   r9,0
 370:   81 22 00 4c lwz r9,76(r2)
 374:   75 23 00 01 andis.  r3,r9,1
 378:   40 82 00 14 bne 38c 
 37c:   7d 20 00 a6 mfmsr   r9
 380:   7c 00 01 46 wrteei  0
 384:   7c 00 01 46 wrteei  0
 388:   4e 80 00 20 blr
 38c:   38 e2 00 4c addir7,r2,76
 390:   3d 20 00 01 lis r9,1
 394:   7c c0 38 28 lwarx   r6,0,r7
 398:   7c c6 48 78 andcr6,r6,r9
 39c:   7c c0 39 2d stwcx.  r6,0,r7
 3a0:   40 a2 ff f4 bne 394 
 3a4:   38 60 00 01 li  r3,1
 3a8:   4b ff ff d4 b   37c 


Re: [PATCH v5 20/22] powerpc/syscall: Avoid storing 'current' in another pointer

2021-02-10 Thread Christophe Leroy




Le 10/02/2021 à 03:00, Nicholas Piggin a écrit :

Excerpts from Christophe Leroy's message of February 10, 2021 3:03 am:



Le 09/02/2021 à 15:31, David Laight a écrit :

From: Segher Boessenkool

Sent: 09 February 2021 13:51

On Tue, Feb 09, 2021 at 12:36:20PM +1000, Nicholas Piggin wrote:

What if you did this?



+static inline struct task_struct *get_current(void)
+{
+   register struct task_struct *task asm ("r2");
+
+   return task;
+}


Local register asm variables are *only* guaranteed to live in that
register as operands to an asm.  See

https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html#Local-Register-Variables
("The only supported use" etc.)

You can do something like

static inline struct task_struct *get_current(void)
{
register struct task_struct *task asm ("r2");

asm("" : "+r"(task));

return task;
}

which makes sure that "task" actually is in r2 at the point of that asm.


If "r2" always contains current (and is never assigned by the compiler)
why not use a global register variable for it?




The change proposed by Nick doesn't solve the issue.


It seemed to change code generation in a simple test case, oh well.



The problem is that at the begining of the function we have:

unsigned long *ti_flagsp = _thread_info()->flags;

When the function uses ti_flagsp for the first time, it does use 112(r2)

Then the function calls some other functions.

Most likely because the function could update 'current', GCC copies r2 into 
r30, so that if r2 get
changed by the called function, ti_flagsp is still based on the previous value 
of current.

Allthough we know r2 wont change, GCC doesn't know it. And in order to save r2 
into r30, it needs to
save r30 in the stack.


By using _thread_info()->flags directly instead of this intermediaite 
ti_flagsp pointer, GCC
uses r2 instead instead of doing a copy.


Nick, I don't understand the reason why you need that 'ti_flagsp' local var.


Just to save typing, I don't mind your patch I was just wondering if
current could be improved in general.



Thanks,

I'll post v6 of it as a follow-up of yesterday's two remaining follow-up 
patches.

Christophe


[PATCH v6 3/2] powerpc/syscall: Avoid storing 'current' in another pointer

2021-02-10 Thread Christophe Leroy
By saving the pointer pointing to thread_info.flags, gcc copies r2
in a non-volatile register.

We know 'current' doesn't change, so avoid that intermediaite pointer.

Reduces null_syscall benchmark by 2 cycles (322 => 320 cycles)

On PPC64, gcc seems to know that 'current' is not changing, and it keeps
it in a non volatile register to avoid multiple read of 'current' in paca.

Signed-off-by: Christophe Leroy 
---
v5: Also in interrupt exit prepare
v6: Removed change related to booke current->thread.debug
v7: Rebased on top of "powerpc/32: Handle bookE debugging in C in syscall 
entry/exit"
---
 arch/powerpc/kernel/interrupt.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index f93664ad4a5e..398cd86b6ada 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c
@@ -241,7 +241,6 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
   struct pt_regs *regs,
   long scv)
 {
-   unsigned long *ti_flagsp = _thread_info()->flags;
unsigned long ti_flags;
unsigned long ret = 0;
bool is_not_scv = !IS_ENABLED(CONFIG_PPC_BOOK3S_64) || !scv;
@@ -257,7 +256,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
/* Check whether the syscall is issued inside a restartable sequence */
rseq_syscall(regs);
 
-   ti_flags = *ti_flagsp;
+   ti_flags = current_thread_info()->flags;
 
if (unlikely(r3 >= (unsigned long)-MAX_ERRNO) && is_not_scv) {
if (likely(!(ti_flags & (_TIF_NOERROR | _TIF_RESTOREALL {
@@ -271,7 +270,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
ret = _TIF_RESTOREALL;
else
regs->gpr[3] = r3;
-   clear_bits(_TIF_PERSYSCALL_MASK, ti_flagsp);
+   clear_bits(_TIF_PERSYSCALL_MASK, _thread_info()->flags);
} else {
regs->gpr[3] = r3;
}
@@ -284,7 +283,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
local_irq_disable();
 
 again:
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
while (unlikely(ti_flags & (_TIF_USER_WORK_MASK & ~_TIF_RESTORE_TM))) {
local_irq_enable();
if (ti_flags & _TIF_NEED_RESCHED) {
@@ -300,7 +299,7 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
do_notify_resume(regs, ti_flags);
}
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
}
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && IS_ENABLED(CONFIG_PPC_FPU)) {
@@ -357,7 +356,6 @@ notrace unsigned long syscall_exit_prepare(unsigned long r3,
 #ifndef CONFIG_PPC_BOOK3E_64 /* BOOK3E not yet using this */
 notrace unsigned long interrupt_exit_user_prepare(struct pt_regs *regs, 
unsigned long msr)
 {
-   unsigned long *ti_flagsp = _thread_info()->flags;
unsigned long ti_flags;
unsigned long flags;
unsigned long ret = 0;
@@ -380,7 +378,7 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
local_irq_save(flags);
 
 again:
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
while (unlikely(ti_flags & (_TIF_USER_WORK_MASK & ~_TIF_RESTORE_TM))) {
local_irq_enable(); /* returning to user: may enable */
if (ti_flags & _TIF_NEED_RESCHED) {
@@ -391,7 +389,7 @@ notrace unsigned long interrupt_exit_user_prepare(struct 
pt_regs *regs, unsigned
do_notify_resume(regs, ti_flags);
}
local_irq_disable();
-   ti_flags = READ_ONCE(*ti_flagsp);
+   ti_flags = READ_ONCE(current_thread_info()->flags);
}
 
if (IS_ENABLED(CONFIG_PPC_BOOK3S) && IS_ENABLED(CONFIG_PPC_FPU)) {
@@ -443,7 +441,6 @@ void preempt_schedule_irq(void);
 
 notrace unsigned long interrupt_exit_kernel_prepare(struct pt_regs *regs, 
unsigned long msr)
 {
-   unsigned long *ti_flagsp = _thread_info()->flags;
unsigned long flags;
unsigned long ret = 0;
 #ifdef CONFIG_PPC64
@@ -466,8 +463,8 @@ notrace unsigned long interrupt_exit_kernel_prepare(struct 
pt_regs *regs, unsign
amr = kuap_get_and_check_amr();
 #endif
 
-   if (unlikely(*ti_flagsp & _TIF_EMULATE_STACK_STORE)) {
-   clear_bits(_TIF_EMULATE_STACK_STORE, ti_flagsp);
+   if (unlikely(current_thread_info()->flags & _TIF_EMULATE_STACK_STORE)) {
+   clear_bits(_TIF_EMULATE_STACK_STORE, 
_thread_info()->flags);
ret = 1;
}
 
@@ -479,7 +476,7 @@ notrace unsigned long 

Re: linux-next: build failure after merge of the powerpc tree

2021-02-10 Thread Nicholas Piggin
Excerpts from Stephen Rothwell's message of February 9, 2021 8:19 pm:
> Hi all,
> 
> After merging the powerpc tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
> 
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x0): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x8): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `do_page_fault' defined in .opd 
> section in arch/powerpc/mm/fault.o
> arch/powerpc/kernel/head_64.o:(__ftr_alt_97+0x28): relocation truncated to 
> fit: R_PPC64_REL24 (OPD) against symbol `unknown_exception' defined in .opd 
> section in arch/powerpc/kernel/traps.o
> 
> Not sure exactly which commit caused this, but it is most likkely part
> of a series in the powerpc tree.
> 
> I have left the allyesconfig build broken for today.

Hey Stephen,

Thanks for that, it's due to .noinstr section being put on the other 
side of .text, so all our interrupt handler asm code can't reach them 
directly anymore since the ppc interrupt wrappers patch added noinstr
attribute.

That's not strictly required though, we've used NOKPROBE_SYMBOL okay
until now. If you can take this patch for now, it should get 
allyesconfig to build again. I'll fix it in the powerpc tree before the 
merge window.

Thanks,
Nick
--

diff --git a/arch/powerpc/include/asm/interrupt.h 
b/arch/powerpc/include/asm/interrupt.h
index 4badb3e51c19..fee1e4dd1e84 100644
--- a/arch/powerpc/include/asm/interrupt.h
+++ b/arch/powerpc/include/asm/interrupt.h
@@ -172,6 +172,8 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DECLARE_INTERRUPT_HANDLER_RAW(func)\
__visible long func(struct pt_regs *regs)
 
+#define ppc_noinstr noinline notrace __no_kcsan __no_sanitize_address
+
 /**
  * DEFINE_INTERRUPT_HANDLER_RAW - Define raw interrupt handler function
  * @func:  Function name of the entry point
@@ -198,7 +200,7 @@ static inline void interrupt_nmi_exit_prepare(struct 
pt_regs *regs, struct inter
 #define DEFINE_INTERRUPT_HANDLER_RAW(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
long ret;   \
\
@@ -228,7 +230,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER(func) \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -262,7 +264,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_RET(func) \
 static __always_inline long ##func(struct pt_regs *regs);  \
\
-__visible noinstr long func(struct pt_regs *regs)  \
+__visible ppc_noinstr long func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
long ret;   \
@@ -297,7 +299,7 @@ static __always_inline long ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_ASYNC(func)   \
 static __always_inline void ##func(struct pt_regs *regs);  \
\
-__visible noinstr void func(struct pt_regs *regs)  \
+__visible ppc_noinstr void func(struct pt_regs *regs)  \
 {  \
struct interrupt_state state;   \
\
@@ -331,7 +333,7 @@ static __always_inline void ##func(struct pt_regs *regs)
 #define DEFINE_INTERRUPT_HANDLER_NMI(func) \
 static __always_inline long ##func(struct pt_regs *regs);