[GIT PULL] Please pull powerpc/linux.git powerpc-5.9-5 tag

2020-09-18 Thread Michael Ellerman
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 5.9:

The following changes since commit 4a133eb351ccc275683ad49305d0b04dde903733:

  powerpc/32s: Disable VMAP stack which CONFIG_ADB_PMU (2020-08-28 12:03:18 
+1000)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.9-5

for you to fetch changes up to 0460534b532e5518c657c7d6492b9337d975eaa3:

  powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute 
(2020-09-09 14:44:38 +1000)

- --
powerpc fixes for 5.9 #5

Opt us out of the DEBUG_VM_PGTABLE support for now as it's causing crashes.

Fix a long standing bug in our DMA mask handling that was hidden until recently,
and which caused problems with some drivers.

Fix a boot failure on systems with large amounts of RAM, and no hugepage support
and using Radix MMU, only seen in the lab.

A few other minor fixes.

Thanks to:
  Alexey Kardashevskiy, Aneesh Kumar K.V, Gautham R. Shenoy, Hari Bathini, Ira
  Weiny, Nick Desaulniers, Shirisha Ganta, Vaibhav Jain, Vaidyanathan
  Srinivasan.

- --
Alexey Kardashevskiy (1):
  powerpc/dma: Fix dma_map_ops::get_required_mask

Aneesh Kumar K.V (2):
  powerpc/book3s64/radix: Fix boot failure with large amount of guest memory
  powerpc/mm: Remove DEBUG_VM_PGTABLE support on powerpc

Gautham R. Shenoy (1):
  cpuidle: pseries: Fix CEDE latency conversion from tb to us

Michael Ellerman (2):
  selftests/powerpc: Skip PROT_SAO test in guests/LPARS
  Revert "powerpc/build: vdso linker warning for orphan sections"

Vaibhav Jain (1):
  powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute


 Documentation/features/debug/debug-vm-pgtable/arch-support.txt |  2 +-
 arch/powerpc/Kconfig   |  1 -
 arch/powerpc/include/asm/book3s/64/mmu.h   | 10 +-
 arch/powerpc/kernel/dma-iommu.c|  3 ++-
 arch/powerpc/kernel/vdso32/Makefile|  2 +-
 arch/powerpc/kernel/vdso32/vdso32.lds.S|  1 -
 arch/powerpc/kernel/vdso64/Makefile|  2 +-
 arch/powerpc/kernel/vdso64/vdso64.lds.S|  3 +--
 arch/powerpc/mm/book3s64/radix_pgtable.c   | 15 
---
 arch/powerpc/mm/init_64.c  | 11 +--
 arch/powerpc/platforms/pseries/papr_scm.c  |  2 +-
 drivers/cpuidle/cpuidle-pseries.c  | 15 
+++
 tools/testing/selftests/powerpc/mm/prot_sao.c  |  9 +++--
 13 files changed, 39 insertions(+), 37 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl9kpeIACgkQUevqPMjh
pYC4aQ/9HwhZgP4aLepJ51l+SajCw7GkDco50MorgjJQLgP2t2Yua/bE2VdB4V4E
PFKq0ZFXytFRT6/njIFZVDsvrL5RbEyN5vHq7hwrmR3B+VJybQOzdyxncZUBlP7n
RZAQS/MvMAu+OR2NFG0QLo9zx4FA9QKMEVYbr20Eftw4l613hP6yV+ubxYR/ww/S
JvZw7JlyBRQfvpH8rb2x2sa1CLtPWGrZyUKWOQx8CTdIClgO7oghMGKAz5PyL+li
AyaIT5e9QKJw5qNUI7Mv56oat+dBHz0xRKSEhrYhjU9LfJ7HBCK23C7l3Wzw5OQO
94t3aAaCIa67uPk2TMdblM8aUN75hKxmRHg5GIBfTyhQKlWptb7A4M6BVd9sDm+d
ggoF+LOZfypoM/xgFPAvVtdyacmRHfhZ+OHILPsTL3IKZRK2Lmr6CgJgY12Dzelk
HudpQW58Egq/ZxwHH66UN6JzteYq7H6oKW7qmiJFftWm00Z78uSFlwFv9dX6aj1W
CGVcANquLY5x6WjrYr2HZa5dfU3rnSRNMrTrXz9S6+ctboGl63pkIfWS1dQ4nB/7
9SmPVivCK/gb1Sdv9LogGYTAgPgBUbC5lYzg1NlR3hOXyWre5P+do68RZFzujCtS
EO4Phx+h+duzLXth35dQQ3tkhn2u3S7tuuXq0s4KT8ZD2TRWc8I=
=UdKu
-END PGP SIGNATURE-


Re: [PATCH v2 1/4] mm: fix exec activate_mm vs TLB shootdown and lazy tlb switching race

2020-09-18 Thread Michael Ellerman
Nicholas Piggin  writes:
> Excerpts from pet...@infradead.org's message of September 14, 2020 8:56 pm:
>> On Mon, Sep 14, 2020 at 02:52:16PM +1000, Nicholas Piggin wrote:
>>> Reading and modifying current->mm and current->active_mm and switching
>>> mm should be done with irqs off, to prevent races seeing an intermediate
>>> state.
...
>>> 
>>> This is a bit ugly, but in the interest of fixing the bug and backporting
>>> before all architectures are converted this is a compromise.
>>> 
>>> Signed-off-by: Nicholas Piggin 
>> 
>> Acked-by: Peter Zijlstra (Intel) 
>> 
>> I'm thinking we want this selected on x86 as well. Andy?
>
> Thanks for the ack. The plan was to take it through the powerpc tree,
> but if you'd want x86 to select it, maybe a topic branch?

I've put this series in a topic branch based on v5.9-rc2:

  
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/log/?h=topic/irqs-off-activate-mm

I plan to merge it into the powerpc/next tree for v5.10, but if anyone
else wants to merge it that's fine too.

cheers


Re: [PATCH 6/6] powerpc/64: irq replay remove decrementer overflow check

2020-09-18 Thread Michael Ellerman
Nicholas Piggin  writes:
> This is an ad-hoc way to catch some cases of decrementer overflow. It
> won't catch cases where interrupts were hard disabled before any soft
> masked interrupts fired, for example. And it doesn't catch cases that
> have overflowed an even number of times.
>
> It's not clear what exactly what problem s being solved here. A lost
> timer when we have an IRQ off latency of more than ~4.3 seconds could
> be avoided (so long as it's also less than ~8.6s) but this is already
> a hard lockup order of magnitude event, and the decrementer will wrap
> again and provide a timer interrupt within the same latency magnitdue.
>
> So the test catches some cases of lost decrementers in very exceptional
> (buggy) latency event cases, reducing timer interrupt latency in that
> case by up to 4.3 seconds. And for large decrementer, it's useless. It
> is performed in potentially quite a hot path, reading the TB can be
> a noticable overhead.
>
> Perhaps more importantly it allows the clunky MSR[EE] vs
> PACA_IRQ_HARD_DIS incoherency to be removed.
>
> Signed-off-by: Nicholas Piggin 
> ---
>  arch/powerpc/kernel/irq.c | 50 +--
>  1 file changed, 1 insertion(+), 49 deletions(-)

Seems to be unhappy on qemu ppc64e:

  kernel BUG at arch/powerpc/kernel/irq.c:153!

Which is:

notrace unsigned int __check_irq_replay(void)
{
...

/* There should be nothing left ! */
BUG_ON(local_paca->irq_happened != 0);

return 0;
}

Full log below.

cheers


spawn qemu-system-ppc64 -nographic -M ppce500 -cpu e5500 -m 2G -kernel 
/home/michael/build/adhoc/ci_output/build/corenet64_smp_defconfig@ppc64@korg@10.1.0/uImage
 -initrd ppc64-novsx-rootfs.cpio.gz -append noreboot
MMU: Supported page sizes
 4 KB as direct
  4096 KB as direct
 16384 KB as direct
 65536 KB as direct
262144 KB as direct
   1048576 KB as direct
MMU: Book3E HW tablewalk not supported
Linux version 5.9.0-rc2-00187-gf523995cc1ee (linuxppc@e054daee57c9) 
(powerpc64-linux-gnu-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34) #1 SMP Fri 
Sep 18 11:52:25 Australia 2020
Found initrd at 0xc500:0xc51e9a47
Using QEMU e500 machine description
ioremap() called early from .find_legacy_serial_ports+0x6cc/0x7bc. Use 
early_ioremap() instead
printk: bootconsole [udbg0] enabled
CPU maps initialized for 1 thread per core
-
phys_mem_size = 0x8000
dcache_bsize  = 0x40
icache_bsize  = 0x40
cpu_features  = 0x0003008001b4
  possible= 0x0003009003b6
  always  = 0x0003008003b4
cpu_user_features = 0xcc008000 0x0800
mmu_features  = 0x000a0010
firmware_features = 0x
-
qemu_e500_setup_arch()
barrier-nospec: using isync; sync as speculation barrier
Zone ranges:
  DMA  [mem 0x-0x7fff]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x-0x7fff]
Initmem setup node 0 [mem 0x-0x7fff]
MMU: Allocated 2112 bytes of context maps for 255 contexts
percpu: Embedded 28 pages/cpu s77400 r0 d37288 u1048576
Built 1 zonelists, mobility grouping on.  Total pages: 517120
Kernel command line: noreboot
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 1977432K/2097152K available (12048K kernel code, 2204K rwdata, 3788K 
rodata, 460K init, 321K bss, 119720K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Hierarchical RCU implementation.
rcu:RCU event tracing is enabled.
rcu:RCU restricting CPUs from NR_CPUS=24 to nr_cpu_ids=1.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
mpic: Setting up MPIC " OpenPIC  " version 1.2 at fe004, max 1 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
random: get_random_u64 called from .start_kernel+0x498/0x70c with crng_init=0
clocksource: timebase: mask: 0x max_cycles: 0x5c4093a7d1, 
max_idle_ns: 440795210635 ns
clocksource: timebase mult[280] shift[24] registered
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
e500 family performance monitor hardware support registered
rcu: Hierarchical SRCU implementation.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
devtmpfs: initialized
clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 
764504178510 ns
futex hash table entries: 

Re: [PATCH v6 0/8] powerpc/watchpoint: Bug fixes plus new feature flag

2020-09-18 Thread Michael Ellerman
Rogerio Alves  writes:
> On 9/2/20 1:29 AM, Ravi Bangoria wrote:
>> Patch #1 fixes issue for quardword instruction on p10 predecessors.
>> Patch #2 fixes issue for vector instructions.
>> Patch #3 fixes a bug about watchpoint not firing when created with
>>   ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
>>   The fix uses HW_BRK_TYPE_PRIV_ALL for ptrace user which, I
>>   guess, should be fine because we don't leak any kernel
>>   addresses and PRIV_ALL will also help to cover scenarios when
>>   kernel accesses user memory.
>> Patch #4,#5 fixes infinite exception bug, again the bug happens only
>>   with CONFIG_HAVE_HW_BREAKPOINT=N.
>> Patch #6 fixes two places where we are missing to set hw_len.
>> Patch #7 introduce new feature bit PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
>>   which will be set when running on ISA 3.1 compliant machine.
>> Patch #8 finally adds selftest to test scenarios fixed by patch#2,#3
>>   and also moves MODE_EXACT tests outside of BP_RANGE condition.
>> 
>> Christophe, let me know if this series breaks something for 8xx.
>> 
>> v5: 
>> https://lore.kernel.org/r/20200825043617.1073634-1-ravi.bango...@linux.ibm.com
>> 
>> v5->v6:
>>   - Fix build faulure reported by kernel test robot
>>   - patch #5. Use more compact if condition, suggested by Christophe
>> 
>> 
>> Ravi Bangoria (8):
>>powerpc/watchpoint: Fix quarword instruction handling on p10
>>  predecessors
>>powerpc/watchpoint: Fix handling of vector instructions
>>powerpc/watchpoint/ptrace: Fix SETHWDEBUG when
>>  CONFIG_HAVE_HW_BREAKPOINT=N
>>powerpc/watchpoint: Move DAWR detection logic outside of
>>  hw_breakpoint.c
>>powerpc/watchpoint: Fix exception handling for
>>  CONFIG_HAVE_HW_BREAKPOINT=N
>>powerpc/watchpoint: Add hw_len wherever missing
>>powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
>>powerpc/watchpoint/selftests: Tests for kernel accessing user memory
>> 
>>   Documentation/powerpc/ptrace.rst  |   1 +
>>   arch/powerpc/include/asm/hw_breakpoint.h  |  12 ++
>>   arch/powerpc/include/uapi/asm/ptrace.h|   1 +
>>   arch/powerpc/kernel/Makefile  |   3 +-
>>   arch/powerpc/kernel/hw_breakpoint.c   | 149 +---
>>   .../kernel/hw_breakpoint_constraints.c| 162 ++
>>   arch/powerpc/kernel/process.c |  48 ++
>>   arch/powerpc/kernel/ptrace/ptrace-noadv.c |   9 +-
>>   arch/powerpc/xmon/xmon.c  |   1 +
>>   .../selftests/powerpc/ptrace/ptrace-hwbreak.c |  48 +-
>>   10 files changed, 282 insertions(+), 152 deletions(-)
>>   create mode 100644 arch/powerpc/kernel/hw_breakpoint_constraints.c
>> 
>
> Tested this patch set for:
> - SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N = OK
> - Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N = OK
> - Check for PPC_DEBUG_FEATURE_DATA_BP_ARCH_31 = OK
> - Fix quarword instruction handling on p10 predecessors = OK
> - Fix handling of vector instructions = OK
>
> Also tested for:
> - Set second watchpoint (P10 Mambo) = OK
> - Infinity loop on sc instruction = OK

Thanks.

I wasn't able to pick up your Tested-by tags as I'd already applied the
patches, but thanks for sending them anyway, they will live on in the
mailing list archives for eternity.

cheers


Re: [PATCH v2 1/2] powerpc/64: Set up a kernel stack for secondaries before cpu_restore()

2020-09-18 Thread Michael Ellerman
Hi Jordan,

Jordan Niethe  writes:
> Currently in generic_secondary_smp_init(), cur_cpu_spec->cpu_restore()
> is called before a stack has been set up in r1. This was previously fine
> as the cpu_restore() functions were implemented in assembly and did not
> use a stack. However commit 5a61ef74f269 ("powerpc/64s: Support new
> device tree binding for discovering CPU features") used
> __restore_cpu_cpufeatures() as the cpu_restore() function for a
> device-tree features based cputable entry. This is a C function and
> hence uses a stack in r1.
>
> generic_secondary_smp_init() is entered on the secondary cpus via the
> primary cpu using the OPAL call opal_start_cpu(). In OPAL, each hardware
> thread has its own stack. The OPAL call is ran in the primary's hardware
> thread. During the call, a job is scheduled on a secondary cpu that will
> start executing at the address of generic_secondary_smp_init().  Hence
> the value that will be left in r1 when the secondary cpu enters the
> kernel is part of that secondary cpu's individual OPAL stack. This means
> that __restore_cpu_cpufeatures() will write to that OPAL stack. This is
> not horribly bad as each hardware thread has its own stack and the call
> that enters the kernel from OPAL never returns, but it is still wrong
> and should be corrected.
>
> Create the temp kernel stack before calling cpu_restore().
>
> Fixes: 5a61ef74f269 ("powerpc/64s: Support new device tree binding for 
> discovering CPU features")
> Signed-off-by: Jordan Niethe 
> ---
> v2: Add more detail to the commit message
> ---
>  arch/powerpc/kernel/head_64.S | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

Unfortunately this breaks booting via kexec.

In that case the secondaries come in to 0x60 and spin until they're
released by smp_release_cpus(), which is before emergency_stack_init()
has run. That means they pick up a bad r1 value and crash/get stuck.

I'm not sure what the best solution is.

I've thought in the past that it would be nicer if the CPU setup didn't
run until the secondary is told to start (via PACAPROCSTART), ie. more
the CPU setup call below there.

But that opens the possibility that we run threads with different
settings of some SPRs until SMP bringup, and if the user has said not to
start secondaries then possibly for ever. And I haven't though hard
enough about whether that's actually problematic (running with different
SPR values).

cheers


> diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> index 0e05a9a47a4b..4b7f4c6c2600 100644
> --- a/arch/powerpc/kernel/head_64.S
> +++ b/arch/powerpc/kernel/head_64.S
> @@ -420,6 +420,10 @@ generic_secondary_common_init:
>   /* From now on, r24 is expected to be logical cpuid */
>   mr  r24,r5
>  
> + /* Create a temp kernel stack for use before relocation is on.  */
> + ld  r1,PACAEMERGSP(r13)
> + subir1,r1,STACK_FRAME_OVERHEAD
> +
>   /* See if we need to call a cpu state restore handler */
>   LOAD_REG_ADDR(r23, cur_cpu_spec)
>   ld  r23,0(r23)
> @@ -448,10 +452,6 @@ generic_secondary_common_init:
>   sync/* order paca.run and cur_cpu_spec */
>   isync   /* In case code patching happened */
>  
> - /* Create a temp kernel stack for use before relocation is on.  */
> - ld  r1,PACAEMERGSP(r13)
> - subir1,r1,STACK_FRAME_OVERHEAD
> -
>   b   __secondary_start
>  #endif /* SMP */
>  
> -- 
> 2.17.1


Re: [PATCH 2/3] powerpc/mce: Add debugfs interface to inject MCE

2020-09-18 Thread Michael Ellerman
Hi Ganesh,

Ganesh Goudar  writes:
> To test machine check handling, add debugfs interface to inject
> slb multihit errors.
>
> To inject slb multihit:
>  #echo 1 > /sys/kernel/debug/powerpc/mce_error_inject/inject_slb_multihit

Rather than creating a new ad-hoc way to trigger this, can you please
integrate it into drivers/misc/lkdtm.

There's enough code here that I think you should create
drivers/misc/lkdtm/powerpc.c and put the code in there. Then add an
LKDTM entry point for this, maybe called PPC_SLB_MULTIHIT.

Please Cc Kees when you repost.

cheers


>  arch/powerpc/Kconfig.debug |   9 ++
>  arch/powerpc/sysdev/Makefile   |   2 +
>  arch/powerpc/sysdev/mce_error_inject.c | 148 +
>  3 files changed, 159 insertions(+)
>  create mode 100644 arch/powerpc/sysdev/mce_error_inject.c
>
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index b88900f4832f..61db133f2f0d 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -398,3 +398,12 @@ config KASAN_SHADOW_OFFSET
>   hex
>   depends on KASAN
>   default 0xe000
> +
> +config MCE_ERROR_INJECT
> + bool "Enable MCE error injection through debugfs"
> + depends on DEBUG_FS
> + default y
> + help
> +   This option creates an mce_error_inject directory in the
> +   powerpc debugfs directory that allows limited injection of
> +   Machine Check Errors (MCEs).
> diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
> index 026b3f01a991..7fc10b77 100644
> --- a/arch/powerpc/sysdev/Makefile
> +++ b/arch/powerpc/sysdev/Makefile
> @@ -52,3 +52,5 @@ obj-$(CONFIG_PPC_XICS)  += xics/
>  obj-$(CONFIG_PPC_XIVE)   += xive/
>  
>  obj-$(CONFIG_GE_FPGA)+= ge/
> +
> +obj-$(CONFIG_MCE_ERROR_INJECT)   += mce_error_inject.o
> diff --git a/arch/powerpc/sysdev/mce_error_inject.c 
> b/arch/powerpc/sysdev/mce_error_inject.c
> new file mode 100644
> index ..ca4726bfa2d9
> --- /dev/null
> +++ b/arch/powerpc/sysdev/mce_error_inject.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Machine Check Exception injection code
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static inline unsigned long get_slb_index(void)
> +{
> + unsigned long index;
> +
> + index = get_paca()->stab_rr;
> +
> + /*
> +  * simple round-robin replacement of slb starting at SLB_NUM_BOLTED.
> +  */
> + if (index < (mmu_slb_size - 1))
> + index++;
> + else
> + index = SLB_NUM_BOLTED;
> + get_paca()->stab_rr = index;
> + return index;
> +}
> +
> +#define slb_esid_mask(ssize) \
> + (((ssize) == MMU_SEGSIZE_256M) ? ESID_MASK : ESID_MASK_1T)
> +
> +static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
> +  unsigned long slot)
> +{
> + return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
> +}
> +
> +#define slb_vsid_shift(ssize)\
> + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
> +
> +static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
> +  unsigned long flags)
> +{
> + return (get_kernel_vsid(ea, ssize) << slb_vsid_shift(ssize)) | flags |
> + ((unsigned long)ssize << SLB_VSID_SSIZE_SHIFT);
> +}
> +
> +static void insert_slb_entry(char *p, int ssize)
> +{
> + unsigned long flags, entry;
> + struct paca_struct *paca;
> +
> + flags = SLB_VSID_KERNEL | mmu_psize_defs[MMU_PAGE_64K].sllp;
> +
> + preempt_disable();
> +
> + paca = get_paca();
> +
> + entry = get_slb_index();
> + asm volatile("slbmte %0,%1" :
> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
> +   "r" (mk_esid_data((unsigned long)p, ssize, entry))
> + : "memory");
> +
> + entry = get_slb_index();
> + asm volatile("slbmte %0,%1" :
> + : "r" (mk_vsid_data((unsigned long)p, ssize, flags)),
> +   "r" (mk_esid_data((unsigned long)p, ssize, entry))
> + : "memory");
> + preempt_enable();
> + p[0] = '!';
> +}
> +
> +static void inject_vmalloc_slb_multihit(void)
> +{
> + char *p;
> +
> + p = vmalloc(2048);
> + if (!p)
> + return;
> +
> + insert_slb_entry(p, MMU_SEGSIZE_1T);
> + vfree(p);
> +}
> +
> +static void inject_kmalloc_slb_multihit(void)
> +{
> + char *p;
> +
> + p = kmalloc(2048, GFP_KERNEL);
> + if (!p)
> + return;
> +
> + insert_slb_entry(p, MMU_SEGSIZE_1T);
> + kfree(p);
> +}
> +
> +static ssize_t inject_slb_multihit(const char __user *u_buf, size_t count)
> +{
> + char buf[32];
> + size_t buf_size;
> +
> + buf_size = min(count, (sizeof(buf) - 1));
> + if (copy_from_user(buf, u_buf, buf_size))
> + 

Re: [PATCH -next] ide: Fix symbol undeclared warnings

2020-09-18 Thread Michael Ellerman
David Miller  writes:
> From: Michael Ellerman 
> Date: Thu, 17 Sep 2020 22:01:00 +1000
>
>> Wang Wensheng  writes:
>>> Build the object file with `C=2` and get the following warnings:
>>> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
>>> make C=2 drivers/ide/pmac.o ARCH=powerpc64
>>> CROSS_COMPILE=powerpc64-linux-gnu-
>>>
>>> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
>>> declared. Should it be static?
>>>
>>> Signed-off-by: Wang Wensheng 
>>> ---
>>>  drivers/ide/pmac.c | 10 +-
>>>  1 file changed, 5 insertions(+), 5 deletions(-)
>> 
>> TIL davem maintains IDE?
>> 
>> But I suspect he isn't that interested in this powerpc only driver, so
>> I'll grab this.
>
> I did have it in my queue, but if you want to take it that's fine too :)

That's OK, if you've got it already you take it. Thanks.

cheers


Re: [PATCH] selftests/seccomp: fix ptrace tests on powerpc

2020-09-18 Thread Michael Ellerman
Thadeu Lima de Souza Cascardo  writes:
> On Thu, Sep 17, 2020 at 03:37:16PM -0700, Kees Cook wrote:
>> On Sun, Sep 13, 2020 at 10:34:23PM +1000, Michael Ellerman wrote:
>> > Thadeu Lima de Souza Cascardo  writes:
>> > > On Tue, Sep 08, 2020 at 04:18:17PM -0700, Kees Cook wrote:
>> > >> On Tue, Jun 30, 2020 at 01:47:39PM -0300, Thadeu Lima de Souza Cascardo 
>> > >> wrote:
>> > ...
>> > >> > @@ -1809,10 +1818,15 @@ void tracer_ptrace(struct __test_metadata 
>> > >> > *_metadata, pid_t tracee,
>> > >> >   EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
>> > >> >   : PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
>> > >> >  
>> > >> > - if (!entry)
>> > >> > + if (!entry && !syscall_nr)
>> > >> >   return;
>> > >> >  
>> > >> > - nr = get_syscall(_metadata, tracee);
>> > >> > + if (entry)
>> > >> > + nr = get_syscall(_metadata, tracee);
>> > >> > + else
>> > >> > + nr = *syscall_nr;
>> > >> 
>> > >> This is weird? Shouldn't get_syscall() be modified to do the right thing
>> > >> here instead of depending on the extra arg?
>> > >> 
>> > >
>> > > R0 might be clobered. Same documentation mentions it as volatile. So, 
>> > > during
>> > > syscall exit, we can't tell for sure that R0 will have the original 
>> > > syscall
>> > > number. So, we need to grab it during syscall enter, save it somewhere 
>> > > and
>> > > reuse it. I used the test context/args for that.
>> > 
>> > The user r0 (in regs->gpr[0]) shouldn't be clobbered.
>> > 
>> > But it is modified if the tracer skips the syscall, by setting the
>> > syscall number to -1. Or if the tracer changes the syscall number.
>> > 
>> > So if you need the original syscall number in the exit path then I think
>> > you do need to save it at entry.
>> 
>> ... the selftest code wants to test the updated syscall (-1 or
>> whatever), so this sounds correct. Was this test actually failing on
>> powerpc? (I'd really rather not split entry/exit if I don't have to.)
>
> Yes, it started failing when the return code started being changed as well.
> Though ptrace can change the syscall at entry (IIRC), it can't change the
> return code. And that is part of the ABI. If ppc is changed so it allows
> changing the return code during ptrace entry, some strace uses will break. So
> that is not an option.

Yep.

I don't know that it would break anything to change that part of the
ptrace ABI, but it definitely could break things and it would be subtle,
so it's not really an option.

So for powerpc we do need the return code change done in the exit hook,
sorry.

cheers


Re: [PATCH] powerpc/perf: Exclude pmc5/6 from the irrelevant PMU group constraints

2020-09-17 Thread Michael Ellerman
Athira Rajeev  writes:
> PMU counter support functions enforces event constraints for group of
> events to check if all events in a group can be monitored. Incase of
> event codes using PMC5 and PMC6 ( 500fa and 600f4 respectively ),
> not all constraints are applicable, say the threshold or sample bits.
> But current code includes pmc5 and pmc6 in some group constraints (like
> IC_DC Qualifier bits) which is actually not applicable and hence results
> in those events not getting counted when scheduled along with group of
> other events. Patch fixes this by excluding PMC5/6 from constraints
> which are not relevant for it.
>
> Fixes: 7ffd948 ('powerpc/perf: factor out power8 pmu functions')
> Signed-off-by: Athira Rajeev 
> ---
>  arch/powerpc/perf/isa207-common.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/perf/isa207-common.c 
> b/arch/powerpc/perf/isa207-common.c
> index 964437a..186fad8 100644
> --- a/arch/powerpc/perf/isa207-common.c
> +++ b/arch/powerpc/perf/isa207-common.c
> @@ -288,6 +288,9 @@ int isa207_get_constraint(u64 event, unsigned long 
> *maskp, unsigned long *valp)
>  
>   mask  |= CNST_PMC_MASK(pmc);
>   value |= CNST_PMC_VAL(pmc);
> +
> + if (pmc >= 5)
> + goto ebb_bhrb;

This is fairly subtle. Can you please put a block comment above the if
explaining in a few lines what's going on.

cheers


Re: [PATCH -next] ide: Fix symbol undeclared warnings

2020-09-17 Thread Michael Ellerman
Wang Wensheng  writes:
> Build the object file with `C=2` and get the following warnings:
> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
> make C=2 drivers/ide/pmac.o ARCH=powerpc64
> CROSS_COMPILE=powerpc64-linux-gnu-
>
> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
> declared. Should it be static?
> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
> declared. Should it be static?
> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
> declared. Should it be static?
> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
> declared. Should it be static?
> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
> declared. Should it be static?
>
> Signed-off-by: Wang Wensheng 
> ---
>  drivers/ide/pmac.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

TIL davem maintains IDE?

But I suspect he isn't that interested in this powerpc only driver, so
I'll grab this.

cheers


> diff --git a/drivers/ide/pmac.c b/drivers/ide/pmac.c
> index ea0b064b5f56..6bb2fc6755c2 100644
> --- a/drivers/ide/pmac.c
> +++ b/drivers/ide/pmac.c
> @@ -225,7 +225,7 @@ struct mdma_timings_t {
>   int cycleTime;
>  };
>  
> -struct mdma_timings_t mdma_timings_33[] =
> +static struct mdma_timings_t mdma_timings_33[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -238,7 +238,7 @@ struct mdma_timings_t mdma_timings_33[] =
>  {   0,   0,   0 }
>  };
>  
> -struct mdma_timings_t mdma_timings_33k[] =
> +static struct mdma_timings_t mdma_timings_33k[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -251,7 +251,7 @@ struct mdma_timings_t mdma_timings_33k[] =
>  {   0,   0,   0 }
>  };
>  
> -struct mdma_timings_t mdma_timings_66[] =
> +static struct mdma_timings_t mdma_timings_66[] =
>  {
>  { 240, 240, 480 },
>  { 180, 180, 360 },
> @@ -265,7 +265,7 @@ struct mdma_timings_t mdma_timings_66[] =
>  };
>  
>  /* KeyLargo ATA-4 Ultra DMA timings (rounded) */
> -struct {
> +static struct {
>   int addrSetup; /* ??? */
>   int rdy2pause;
>   int wrDataSetup;
> @@ -1415,7 +1415,7 @@ static struct pci_driver pmac_ide_pci_driver = {
>  };
>  MODULE_DEVICE_TABLE(pci, pmac_ide_pci_match);
>  
> -int __init pmac_ide_probe(void)
> +static int __init pmac_ide_probe(void)
>  {
>   int error;
>  
> -- 
> 2.25.0


Re: [PATCH v2] powerpc: fix EDEADLOCK redefinition error in uapi/asm/errno.h

2020-09-17 Thread Michael Ellerman
[ Cc += linux-arch & Arnd ]

Hi Tony,

This looks OK to me, but I'm always a bit nervous about changes in uapi.
I've Cc'ed linux-arch and Arnd who look after the asm-generic headers,
which this is slightly related to, just in case.

One minor comment below.

Tony Ambardar  writes:
> A few archs like powerpc have different errno.h values for macros
> EDEADLOCK and EDEADLK. In code including both libc and linux versions of
> errno.h, this can result in multiple definitions of EDEADLOCK in the
> include chain. Definitions to the same value (e.g. seen with mips) do
> not raise warnings, but on powerpc there are redefinitions changing the
> value, which raise warnings and errors (if using "-Werror").
>
> Guard against these redefinitions to avoid build errors like the following,
> first seen cross-compiling libbpf v5.8.9 for powerpc using GCC 8.4.0 with
> musl 1.1.24:
>
>   In file included from ../../arch/powerpc/include/uapi/asm/errno.h:5,
>from ../../include/linux/err.h:8,
>from libbpf.c:29:
>   ../../include/uapi/asm-generic/errno.h:40: error: "EDEADLOCK" redefined 
> [-Werror]
>#define EDEADLOCK EDEADLK
>
>   In file included from 
> toolchain-powerpc_8540_gcc-8.4.0_musl/include/errno.h:10,
>from libbpf.c:26:
>   toolchain-powerpc_8540_gcc-8.4.0_musl/include/bits/errno.h:58: note: this 
> is the location of the previous definition
>#define EDEADLOCK   58
>
>   cc1: all warnings being treated as errors
>
> Fixes: 95f28190aa01 ("tools include arch: Grab a copy of errno.h for arch's 
> supported by perf")
> Fixes: c3617f72036c ("UAPI: (Scripted) Disintegrate arch/powerpc/include/asm")

I suspect that's not the right commit to tag. It just moved errno.h from
arch/powerpc/include/asm to arch/powerpc/include/uapi/asm. It's content
was almost identical, and entirely identical as far as EDEADLOCK was
concerned.

Prior to that the file lived in asm-powerpc/errno.h, eg:

$ git cat-file -p b8b572e1015f^:include/asm-powerpc/errno.h

Before that it was include/asm-ppc64/errno.h, content still the same.

To go back further we'd have to look at the historical git trees, which
is probably overkill. I'm pretty sure it's always had this problem.

So we should probably drop the Fixes tags and just Cc: stable, that
means please backport it as far back as possible.

cheers


> Reported-by: Rosen Penev 
> Signed-off-by: Tony Ambardar 
> ---
> v1 -> v2:
>  * clean up commit description formatting
> ---
>  arch/powerpc/include/uapi/asm/errno.h   | 1 +
>  tools/arch/powerpc/include/uapi/asm/errno.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/errno.h 
> b/arch/powerpc/include/uapi/asm/errno.h
> index cc79856896a1..4ba87de32be0 100644
> --- a/arch/powerpc/include/uapi/asm/errno.h
> +++ b/arch/powerpc/include/uapi/asm/errno.h
> @@ -2,6 +2,7 @@
>  #ifndef _ASM_POWERPC_ERRNO_H
>  #define _ASM_POWERPC_ERRNO_H
>  
> +#undef   EDEADLOCK
>  #include 
>  
>  #undef   EDEADLOCK
> diff --git a/tools/arch/powerpc/include/uapi/asm/errno.h 
> b/tools/arch/powerpc/include/uapi/asm/errno.h
> index cc79856896a1..4ba87de32be0 100644
> --- a/tools/arch/powerpc/include/uapi/asm/errno.h
> +++ b/tools/arch/powerpc/include/uapi/asm/errno.h
> @@ -2,6 +2,7 @@
>  #ifndef _ASM_POWERPC_ERRNO_H
>  #define _ASM_POWERPC_ERRNO_H
>  
> +#undef   EDEADLOCK
>  #include 
>  
>  #undef   EDEADLOCK
> -- 
> 2.25.1


Re: [PATCH] powerpc/64: Make VDSO32 track COMPAT on 64-bit

2020-09-17 Thread Michael Ellerman
On Tue, 8 Sep 2020 22:58:50 +1000, Michael Ellerman wrote:
> When we added the VDSO32 kconfig symbol, which controls building of
> the 32-bit VDSO, we made it depend on CPU_BIG_ENDIAN (for 64-bit).
> 
> That was because back then COMPAT was always enabled for 64-bit, so
> depending on it would have left the 32-bit VDSO always enabled, which
> we didn't want.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64: Make VDSO32 track COMPAT on 64-bit
  https://git.kernel.org/powerpc/c/231b232df8f67e7d37af01259c21f2a131c3911e

cheers


Re: [PATCH] powerpc/ps3: make two symbols static

2020-09-17 Thread Michael Ellerman
On Fri, 11 Sep 2020 10:01:21 +0800, Jason Yan wrote:
> This addresses the following sparse warning:
> 
> arch/powerpc/platforms/ps3/spu.c:451:33: warning: symbol
> 'spu_management_ps3_ops' was not declared. Should it be static?
> arch/powerpc/platforms/ps3/spu.c:592:28: warning: symbol
> 'spu_priv1_ps3_ops' was not declared. Should it be static?

Applied to powerpc/next.

[1/1] powerpc/ps3: make two symbols static
  https://git.kernel.org/powerpc/c/bbc4f40b5322b3e0b8678619f1c613dadc811669

cheers


Re: [PATCH -next] drivers/macintosh/smu.c: Fix undeclared symbol warning

2020-09-17 Thread Michael Ellerman
On Mon, 14 Sep 2020 12:26:15 +, Wang Wensheng wrote:
> Make kernel with `C=2`:
> drivers/macintosh/smu.c:1018:30: warning: symbol
> '__smu_get_sdb_partition' was not declared. Should it be static?

Applied to powerpc/next.

[1/1] drivers/macintosh/smu.c: Fix undeclared symbol warning
  https://git.kernel.org/powerpc/c/3db8715ec9dc1d32ecafc67af9fb96508c98efe5

cheers


Re: [PATCH v2] powerpc/papr_scm: Fix warning triggered by perf_stats_show()

2020-09-17 Thread Michael Ellerman
On Sat, 12 Sep 2020 13:44:51 +0530, Vaibhav Jain wrote:
> A warning is reported by the kernel in case perf_stats_show() returns
> an error code. The warning is of the form below:
> 
>  papr_scm ibm,persistent-memory:ibm,pmemory@4411:
> Failed to query performance stats, Err:-10
>  dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count
>  fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/papr_scm: Fix warning triggered by perf_stats_show()
  https://git.kernel.org/powerpc/c/ca78ef2f08ccfa29b711d644964cdf9d7ace15e5

cheers


Re: [PATCH v6 0/3] Offline memoryless cpuless node 0

2020-09-17 Thread Michael Ellerman
On Tue, 18 Aug 2020 13:41:01 +0530, Srikar Dronamraju wrote:
> Changelog v5:->v6:
> - Now the fix is Powerpc specific.
>   (David Hildenbrand, Michal Hocko, Christopher Lamater)
> - rebased to v5.8
> link v5: 
> https://lore.kernel.org/linuxppc-dev/20200624092846.9194-1-sri...@linux.vnet.ibm.com/t/#u
> 
> Changelog v4:->v5:
> - rebased to v5.8
> link v4: 
> http://lore.kernel.org/lkml/20200512132937.19295-1-sri...@linux.vnet.ibm.com/t/#u
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/numa: Set numa_node for all possible cpus
  https://git.kernel.org/powerpc/c/a874f1005ef5dfe53dfd8cda59a6600e89986ecd
[2/3] powerpc/numa: Prefer node id queried from vphn
  https://git.kernel.org/powerpc/c/6398eaa268168b528dd1d3d0e70e61e9c13bea23
[3/3] powerpc/numa: Offline memoryless cpuless node 0
  https://git.kernel.org/powerpc/c/e75130f20b1f48e04ccc806aea01f0a361f9cb6b

cheers


Re: [PATCH v5 00/10] Coregroup support on Powerpc

2020-09-17 Thread Michael Ellerman
On Mon, 10 Aug 2020 12:48:24 +0530, Srikar Dronamraju wrote:
> Changelog v4->v5:
> v4: 
> http://lore.kernel.org/lkml/20200727053230.19753-1-sri...@linux.vnet.ibm.com/t/#u
> 
> Changelog v4 ->v5:
> powerpc/smp: Optimize start_secondary
>   Retain cache domain, no need for generalization
>    (Michael Ellerman, Peter Zijlstra,
>Valentin Schneider, Gautham R. Shenoy)
> 
> [...]

Applied to powerpc/next.

[01/10] powerpc/smp: Fix a warning under !NEED_MULTIPLE_NODES

https://git.kernel.org/powerpc/c/d0fd24bbd27619d7b8d4da26a19a2027931ae9fc
[02/10] powerpc/smp: Merge Power9 topology with Power topology

https://git.kernel.org/powerpc/c/2ef0ca54d97f40f7621d595ac5479bd7fa076bfa
[03/10] powerpc/smp: Move powerpc_topology above

https://git.kernel.org/powerpc/c/5e93f16ae48b728775496429c6db53d0bf8cdd9b
[04/10] powerpc/smp: Move topology fixups into a new function

https://git.kernel.org/powerpc/c/3c6032a8fe99547d31b2b57715e303a67d1b0c66
[05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

https://git.kernel.org/powerpc/c/f6606cfdfbcda00ce8a6e63c8fc13c93e73ac059
[06/10] powerpc/smp: Optimize start_secondary

https://git.kernel.org/powerpc/c/caa8e29da59926bef099b46ab6280333d583e944
[07/10] powerpc/numa: Detect support for coregroup

https://git.kernel.org/powerpc/c/f9f130ff2ec93c5949576bbfb168cc9530c23649
[08/10] powerpc/smp: Allocate cpumask only after searching thread group

https://git.kernel.org/powerpc/c/6e086302816b2ced602bc99641eb0189c05f018a
[09/10] powerpc/smp: Create coregroup domain

https://git.kernel.org/powerpc/c/72730bfc2a2b91a525f38dfc830f598bdb95f216
[10/10] powerpc/smp: Implement cpu_to_coregroup_id

https://git.kernel.org/powerpc/c/fa35e868f9ddcbb7984fd5ab7f91aef924fa8543

cheers


Re: [PATCH v3] powerpc/numa: Restrict possible nodes based on platform

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 11:22:57 +0530, Srikar Dronamraju wrote:
> As per draft LoPAPR (Revision 2.9_pre7), section B.5.3 "Run Time Abstaction
> Services (RTAS) Node at
> https://openpowerfoundation.org/wp-content/uploads/2020/07/LoPAR-20200611.pdf,
> there are 2 device tree property ibm,max-associativity-domains (which
> defines the maximum number of domains that the firmware i.e PowerVM can
> support) and ibm,current-associativity-domains (which defines the maximum
> number of domains that the platform can support). Value of
> ibm,max-associativity-domains property is always greater than or equal to
> ibm,current-associativity-domains property. If the said property is not
> available, use ibm,max-associativity-domain as fallback. In this yet to be
> released LoPAPR, ibm,current-associativity-domains is mentioned in page 833
> / B.5.3 which is covered under under "Appendix B. System Binding" section
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/numa: Restrict possible nodes based on platform
  https://git.kernel.org/powerpc/c/67df77845c181166d4bc324cbb0382f7e81c7631

cheers


Re: [PATCH v2 1/2] sched/topology: Allow archs to override cpu_smt_mask

2020-09-17 Thread Michael Ellerman
On Fri, 7 Aug 2020 13:15:16 +0530, Srikar Dronamraju wrote:
> cpu_smt_mask tracks topology_sibling_cpumask. This would be good for
> most architectures. One of the users of cpu_smt_mask(), would be to
> identify idle-cores. On Power9, a pair of SMT4 cores can be presented by
> the firmware as a SMT8 core for backward compatibility reasons.
> 
> Powerpc allows LPARs to be live migrated from Power8 to Power9. Do note
> Power8 had only SMT8 cores. Existing software which has been
> developed/configured for Power8 would expect to see SMT8 core.
> Maintaining the illusion of SMT8 core is a requirement to make that
> work.
> 
> [...]

Applied to powerpc/next.

[1/2] sched/topology: Allow archs to override cpu_smt_mask
  https://git.kernel.org/powerpc/c/3babbe447d76ac2919ec4d0eb3b0adfb22f5b03c
[2/2] powerpc/topology: Override cpu_smt_mask
  https://git.kernel.org/powerpc/c/f3232321db58480804f80d59aeb651a5c859a200

cheers


Re: [PATCH v6 0/8] powerpc/watchpoint: Bug fixes plus new feature flag

2020-09-17 Thread Michael Ellerman
On Wed, 2 Sep 2020 09:59:37 +0530, Ravi Bangoria wrote:
> Patch #1 fixes issue for quardword instruction on p10 predecessors.
> Patch #2 fixes issue for vector instructions.
> Patch #3 fixes a bug about watchpoint not firing when created with
>  ptrace PPC_PTRACE_SETHWDEBUG and CONFIG_HAVE_HW_BREAKPOINT=N.
>  The fix uses HW_BRK_TYPE_PRIV_ALL for ptrace user which, I
>  guess, should be fine because we don't leak any kernel
>  addresses and PRIV_ALL will also help to cover scenarios when
>  kernel accesses user memory.
> Patch #4,#5 fixes infinite exception bug, again the bug happens only
>  with CONFIG_HAVE_HW_BREAKPOINT=N.
> Patch #6 fixes two places where we are missing to set hw_len.
> Patch #7 introduce new feature bit PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
>  which will be set when running on ISA 3.1 compliant machine.
> Patch #8 finally adds selftest to test scenarios fixed by patch#2,#3
>  and also moves MODE_EXACT tests outside of BP_RANGE condition.
> 
> [...]

Applied to powerpc/next.

[1/8] powerpc/watchpoint: Fix quadword instruction handling on p10 predecessors
  https://git.kernel.org/powerpc/c/4759c11ed20454b7b36db4ec15f7d5aa1519af4a
[2/8] powerpc/watchpoint: Fix handling of vector instructions
  https://git.kernel.org/powerpc/c/4441eb02333a9b46a0d919aa7a6d3b137b5f2562
[3/8] powerpc/watchpoint/ptrace: Fix SETHWDEBUG when CONFIG_HAVE_HW_BREAKPOINT=N
  https://git.kernel.org/powerpc/c/9b6b7c680cc20971444d9f836e49fc98848bcd0a
[4/8] powerpc/watchpoint: Move DAWR detection logic outside of hw_breakpoint.c
  https://git.kernel.org/powerpc/c/edc8dd99b29e4d705c45e2a3a6c01b096ee056db
[5/8] powerpc/watchpoint: Fix exception handling for CONFIG_HAVE_HW_BREAKPOINT=N
  https://git.kernel.org/powerpc/c/5b905d77987de065bdd3a2906816b5f143df087b
[6/8] powerpc/watchpoint: Add hw_len wherever missing
  https://git.kernel.org/powerpc/c/58da5984d2ea6d95f3f9d9e8dd9f7e1b0dddfb3c
[7/8] powerpc/watchpoint/ptrace: Introduce PPC_DEBUG_FEATURE_DATA_BP_ARCH_31
  https://git.kernel.org/powerpc/c/fa725cc53d353110f39a9e5b9f60d6acb2c7ff49
[8/8] selftests/powerpc: Tests for kernel accessing user memory
  https://git.kernel.org/powerpc/c/ac234524056da4e0c081f682da3ea25cdaab737a

cheers


Re: [PATCH] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10

2020-09-17 Thread Michael Ellerman
On Wed, 19 Aug 2020 19:47:00 +1000, Nicholas Piggin wrote:
> This driver does not restore stop > 3 state, so it limits itself
> to states which do not lose full state or TB.
> 
> The POWER10 SPRs are sufficiently different from P9 that it seems
> easier to split out the P10 code. The POWER10 deep sleep code
> (e.g., the BHRB restore) has been taken out, but it can be re-added
> when stop > 3 support is added.

Applied to powerpc/next.

[1/1] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10
  https://git.kernel.org/powerpc/c/ffd2961bb41f797eb00b58e019b707555197275e

cheers


Re: [PATCH 0/5] powerpc/tau: TAU driver fixes

2020-09-17 Thread Michael Ellerman
On Sat, 05 Sep 2020 09:02:20 +1000, Finn Thain wrote:
> This patch series fixes various bugs in the Thermal Assist Unit driver.
> It was tested on 266 MHz and 292 MHz PowerBook G3 laptops.
> 
> 
> Finn Thain (5):
>   powerpc/tau: Use appropriate temperature sample interval
>   powerpc/tau: Convert from timer to workqueue
>   powerpc/tau: Remove duplicated set_thresholds() call
>   powerpc/tau: Check processor type before enabling TAU interrupt
>   powerpc/tau: Disable TAU between measurements
> 
> [...]

Applied to powerpc/next.

[1/5] powerpc/tau: Use appropriate temperature sample interval
  https://git.kernel.org/powerpc/c/66943005cc41f48e4d05614e8f76c0ca1812f0fd
[2/5] powerpc/tau: Convert from timer to workqueue
  https://git.kernel.org/powerpc/c/b1c6a0a10bfaf36ec82fde6f621da72407fa60a1
[3/5] powerpc/tau: Remove duplicated set_thresholds() call
  https://git.kernel.org/powerpc/c/420ab2bc7544d978a5d0762ee736412fe9c796ab
[4/5] powerpc/tau: Check processor type before enabling TAU interrupt
  https://git.kernel.org/powerpc/c/5e3119e15fed5b9a9a7e528665ff098a4a8dbdbc
[5/5] powerpc/tau: Disable TAU between measurements
  https://git.kernel.org/powerpc/c/e63d6fb5637e92725cf143559672a34b706bca4f

cheers


Re: [PATCH -next] macintosh: windfarm: use for_each_child_of_node() macro

2020-09-17 Thread Michael Ellerman
On Mon, 14 Sep 2020 14:14:11 +0800, Qinglang Miao wrote:
> Use for_each_child_of_node() macro instead of open coding it.

Applied to powerpc/next.

[1/1] macintosh: windfarm: use for_each_child_of_node() macro
  https://git.kernel.org/powerpc/c/8f7e57e8e29c4fc788811dd4db96126272b8df91

cheers


Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed

2020-09-17 Thread Michael Ellerman
On Fri, 7 Aug 2020 12:18:54 +0200, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still present, the RTAS call which isolates the PCI slot
> returns error 9001 "valid outstanding translations" and the removal of
> the IO adapter fails. This is because when the PHBs are scanned, Linux
> maps automatically the INTx interrupts in the Linux interrupt number
> space but these are never removed.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
  https://git.kernel.org/powerpc/c/3a3181e16fbde752007759f8759d25e0ff1fc425

cheers


Re: [PATCH v2] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP

2020-09-17 Thread Michael Ellerman
On Fri, 11 Sep 2020 10:29:15 + (UTC), Christophe Leroy wrote:
> low_sleep_handler() has an hardcoded restore of segment registers
> that doesn't take KUAP and KUEP into account.
> 
> Use head_32's load_segment_registers() routine instead.

Applied to powerpc/next.

[1/1] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP
  https://git.kernel.org/powerpc/c/2c637d2df4ee4830e9d3eb2bd5412250522ce96e

cheers


Re: [PATCH v1] powerpc/process: Tag an #endif to help locate the matching #ifdef.

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:45 + (UTC), Christophe Leroy wrote:
> That #endif is more than 100 lines after the matching #ifdef,
> and there are several #ifdef/#else/#endif inbetween.
> 
> Tag it as /* CONFIG_PPC_BOOK3S_64 */ to help locate the
> matching #ifdef.

Applied to powerpc/next.

[1/1] powerpc/process: Tag an #endif to help locate the matching #ifdef.
  https://git.kernel.org/powerpc/c/60d62bfd24efce1a595d259100b8a4e7a489e834

cheers


Re: [PATCH v1] powerpc/process: Replace #ifdef CONFIG_KALLSYMS by IS_ENABLED()

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:44 + (UTC), Christophe Leroy wrote:
> The #ifdef CONFIG_KALLSYMS encloses some printk which can
> compile in all cases.
> 
> Replace by IS_ENABLED().

Applied to powerpc/next.

[1/1] powerpc/process: Replace #ifdef CONFIG_KALLSYMS by IS_ENABLED()
  https://git.kernel.org/powerpc/c/8f020c7ca300fd60374f0347814c92ea513c24da

cheers


Re: [PATCH v1] powerpc/process: Replace an #ifdef CONFIG_PPC_BOOK3S_64 by IS_ENABLED()

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:42 + (UTC), Christophe Leroy wrote:
> This #ifdef CONFIG_PPC_BOOK3S_64 calls preload_new_slb_context()
> when radix is not enabled.
> 
> radix_enabled() is always defined, and the prototype for
> preload_new_slb_context() is always present, so the #ifdef
> is unneeded.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #ifdef CONFIG_PPC_BOOK3S_64 by IS_ENABLED()
  https://git.kernel.org/powerpc/c/bfac2799301c19d81122af04a8a3ad5ecae3737e

cheers


Re: [PATCH v1] powerpc/process: Replace an #ifdef CONFIG_PPC_47x by IS_ENABLED()

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:41 + (UTC), Christophe Leroy wrote:
> isync() is always defined, no need for an #ifdef.
> 
> Replace it by IS_ENABLED(CONFIG_PPC_47x).

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #ifdef CONFIG_PPC_47x by IS_ENABLED()
  https://git.kernel.org/powerpc/c/04d476bfbb06426fef2985c8e53578bb04596a6f

cheers


Re: [PATCH v1] powerpc/process: Replace an #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) by IS_ENABLED()

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:43 + (UTC), Christophe Leroy wrote:
> The #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) encloses some
> printk which can be compiled in all cases.
> 
> Replace by IS_ENABLED().

Applied to powerpc/next.

[1/1] powerpc/process: Replace an #if defined(CONFIG_4xx) || 
defined(CONFIG_BOOKE) by IS_ENABLED()
  https://git.kernel.org/powerpc/c/2ec42996f5b12826466300a755413577b6913206

cheers


Re: [PATCH v1 1/4] powerpc/process: Remove useless #ifdef CONFIG_VSX

2020-09-17 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:47:55 + (UTC), Christophe Leroy wrote:
> cpu_has_feature(CPU_FTR_VSX) returns false when CONFIG_VSX is
> not set.
> 
> There is no need to enclose the test in an #ifdef CONFIG_VSX.
> Remove it.

Applied to powerpc/next.

[1/4] powerpc/process: Remove useless #ifdef CONFIG_VSX
  https://git.kernel.org/powerpc/c/80739c2bd29133715d6828e333649a55095f4747
[2/4] powerpc/process: Remove useless #ifdef CONFIG_ALTIVEC
  https://git.kernel.org/powerpc/c/e3667ee427e224f9951eb3940a97477285548134
[3/4] powerpc/process: Remove useless #ifdef CONFIG_SPE
  https://git.kernel.org/powerpc/c/532ed1900d37a47c821718a0d8d28eb05b2c4d28
[4/4] powerpc/process: Remove useless #ifdef CONFIG_PPC_FPU
  https://git.kernel.org/powerpc/c/c83c192a6fbb1d4db4144c40296ed059f5eca384

cheers


Re: [PATCH] powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()

2020-09-17 Thread Michael Ellerman
On Fri, 4 Sep 2020 10:46:47 + (UTC), Christophe Leroy wrote:
> Enable pre-update addressing mode in __put_user_asm_goto()

Applied to powerpc/next.

[1/1] powerpc/uaccess: Add pre-update addressing to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/fcf1f26895a4f14618b0dc04e0801b123c55e4a3

cheers


Re: [PATCH] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx

2020-09-17 Thread Michael Ellerman
On Fri, 11 Sep 2020 05:05:38 + (UTC), Christophe Leroy wrote:
> Before the commit identified below, pages tables allocation was
> performed after the allocation of final shadow area for linear memory.
> But that commit switched the order, leading to page tables being
> already allocated at the time 8xx kasan_init_shadow_8M() is called.
> Due to this, kasan_init_shadow_8M() doesn't map the needed
> shadow entries because there are already page tables.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/kasan: Fix CONFIG_KASAN_VMALLOC for 8xx
  https://git.kernel.org/powerpc/c/4c42dc5c69a8f24c467a6c997909d2f1d4efdc7f

cheers


Re: [PATCH] powerpc: Fix random segfault when freeing hugetlb range

2020-09-17 Thread Michael Ellerman
On Mon, 31 Aug 2020 07:58:19 + (UTC), Christophe Leroy wrote:
> The following random segfault is observed from time to time with
> map_hugetlb selftest:
> 
> root@localhost:~# ./map_hugetlb 1 19
> 524288 kB hugepages
> Mapping 1 Mbytes
> Segmentation fault
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Fix random segfault when freeing hugetlb range
  https://git.kernel.org/powerpc/c/542db12a9c42d1ce70c45091765e02f74c129f43

cheers


Re: [PATCH 1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()

2020-09-17 Thread Michael Ellerman
On Fri, 4 Sep 2020 11:01:30 + (UTC), Christophe Leroy wrote:
> __put_user_asm_goto() provides more flexibility to GCC and avoids using
> a local variable to tell if the write succeeded or not.
> GCC can then avoid implementing a cmp in the fast path.
> 
> See the difference for a small function like the PPC64 version of
> save_general_regs() in arch/powerpc/kernel/signal_32.c:
> 
> [...]

Applied to powerpc/next.

[1/3] powerpc/uaccess: Switch __put_user_size_allowed() to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/ee0a49a6870ea75e25b4d4984c1bb6b3b7c65f2b
[2/3] powerpc/uaccess: Switch __patch_instruction() to __put_user_asm_goto()
  https://git.kernel.org/powerpc/c/e64ac41ab0c510b3f85199a585eb886cad92fb19
[3/3] powerpc/uaccess: Remove __put_user_asm() and __put_user_asm2()
  https://git.kernel.org/powerpc/c/7fdf966bed155b214f4f1f9b67825a40b2e9b998

cheers


Re: [PATCH 1/2] powerpc/8xx: Refactor calculation of number of entries per PTE in page tables

2020-09-17 Thread Michael Ellerman
On Mon, 31 Aug 2020 08:30:43 + (UTC), Christophe Leroy wrote:
> On 8xx, the number of entries occupied by a PTE in the page tables
> depends on the size of the page. At the time being, this calculation
> is done in two places: in pte_update() and in set_huge_pte_at()
> 
> Refactor this calculation into a helper called
> number_of_cells_per_pte(). For the time being, the val param is
> unused. It will be used by following patch.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/8xx: Refactor calculation of number of entries per PTE in page 
tables
  https://git.kernel.org/powerpc/c/175a1511fed16108dcb823f0af8e72325a1f
[2/2] powerpc/8xx: Support 16k hugepages with 4k pages
  https://git.kernel.org/powerpc/c/e47168f3d1b14af5281cf50c59561d59d28201f9

cheers


Re: [PATCH 1/2] powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct

2020-09-17 Thread Michael Ellerman
On Mon, 7 Sep 2020 13:42:09 + (UTC), Christophe Leroy wrote:
> We need r1 to be properly set before activating MMU, so
> reading task_struct->stack must be done with MMU off.
> 
> This means we need an additional register to play with MSR
> bits while r11 now points to the stack. For that, move r10
> back to CR (As is already done for hash MMU) and use r10.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/32: Fix vmap stack - Do not activate MMU before reading task 
struct
  https://git.kernel.org/powerpc/c/c118c7303ad528be8ff2aea8cd1ee15452c763f0
[2/2] powerpc/32: Fix vmap stack - Properly set r1 before activating MMU
  https://git.kernel.org/powerpc/c/da7bb43ab9da39bcfed0d146ce94e1f0cbae4ca0

cheers


Re: [PATCH v3] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory

2020-09-17 Thread Michael Ellerman
On Tue, 18 Aug 2020 19:11:26 -0300, Thiago Jung Bauermann wrote:
> POWER secure guests (i.e., guests which use the Protection Execution
> Facility) need to use SWIOTLB to be able to do I/O with the hypervisor, but
> they don't need the SWIOTLB memory to be in low addresses since the
> hypervisor doesn't have any addressing limitation.
> 
> This solves a SWIOTLB initialization problem we are seeing in secure guests
> with 128 GB of RAM: they are configured with 4 GB of crashkernel reserved
> memory, which leaves no space for SWIOTLB in low addresses.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pseries/svm: Allocate SWIOTLB buffer anywhere in memory
  https://git.kernel.org/powerpc/c/eae9eec476d13fad9af6da1f44a054ee02b7b161

cheers


Re: [PATCH v2 1/4] powerpc/percpu: Update percpu bootmem allocator

2020-09-17 Thread Michael Ellerman
On Mon, 8 Jun 2020 12:39:01 +0530, Aneesh Kumar K.V wrote:
> This update the ppc64 version to be closer to x86/sparc.

Applied to powerpc/next.

[1/4] powerpc/percpu: Update percpu bootmem allocator
  https://git.kernel.org/powerpc/c/2a32abac8860aa1c3a1fc99973ce67179575b36c
[2/4] powerpc/64/mm: implement page mapping percpu first chunk allocator
  https://git.kernel.org/powerpc/c/eb553f16973ade990d05946af9ae191394712c8a
[3/4] powerpc/book3s64/hash/4k: Support large linear mapping range with 4K
  https://git.kernel.org/powerpc/c/7746406baa3bc9e23fdd7b7da2f04d86e25ab837
[4/4] powerpc/mm/book3s: Split radix and hash MAX_PHYSMEM limit
  https://git.kernel.org/powerpc/c/b32d5d7e920a364287f6206af2d20179978a617d

cheers


Re: [PATCH] powerepc/book3s64/hash: Align start/end address correctly with bolt mapping

2020-09-17 Thread Michael Ellerman
On Mon, 7 Sep 2020 12:55:39 +0530, Aneesh Kumar K.V wrote:
> This ensures we don't do a partial mapping of memory. With nvdimm, when
> creating namespaces with size not aligned to 16MB, the kernel ends up 
> partially
> mapping the pages. This can result in kernel adding multiple hash page table
> entries for the same range. A new namespace will result in
> create_section_mapping() with start and end overlapping an already existing
> bolted hash page table entry.
> 
> [...]

Applied to powerpc/next.

[1/1] powerepc/book3s64/hash: Align start/end address correctly with bolt 
mapping
  https://git.kernel.org/powerpc/c/79b123cdf9cf0d4a1620baa8c611962626323a08

cheers


[PATCH] powerpc/process: Fix uninitialised variable error

2020-09-16 Thread Michael Ellerman
Clang, and GCC with -Wmaybe-uninitialized, can't see that val is
unused in get_fpexec_mode():

  arch/powerpc/kernel/process.c:1940:7: error: variable 'val' is used
  uninitialized whenever 'if' condition is true
  if (cpu_has_feature(CPU_FTR_SPE)) {
  ^~~~

We know that CPU_FTR_SPE will only be true iff CONFIG_SPE is also
true, but the compiler doesn't.

Avoid it by initialising val to zero.

Reported-by: kernel test robot 
Fixes: 532ed1900d37 ("powerpc/process: Remove useless #ifdef CONFIG_SPE")
Signed-off-by: Michael Ellerman 
---
 arch/powerpc/kernel/process.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 14d5189b17d8..d421a2c7f822 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1934,7 +1934,7 @@ int set_fpexc_mode(struct task_struct *tsk, unsigned int 
val)
 
 int get_fpexc_mode(struct task_struct *tsk, unsigned long adr)
 {
-   unsigned int val;
+   unsigned int val = 0;
 
if (tsk->thread.fpexc_mode & PR_FP_EXC_SW_ENABLE) {
if (cpu_has_feature(CPU_FTR_SPE)) {
-- 
2.25.1



[PATCH 1/2] powerpc/mm/64s: Fix slb_setup_new_exec() sparse warning

2020-09-16 Thread Michael Ellerman
Sparse says:
  symbol slb_setup_new_exec was not declared. Should it be static?

No, it should have a declaration in a header, add one.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/mm/book3s64/internal.h| 2 ++
 arch/powerpc/mm/book3s64/mmu_context.c | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/internal.h 
b/arch/powerpc/mm/book3s64/internal.h
index 7eda0d30d765..c12d78ee42f5 100644
--- a/arch/powerpc/mm/book3s64/internal.h
+++ b/arch/powerpc/mm/book3s64/internal.h
@@ -13,4 +13,6 @@ static inline bool stress_slb(void)
return static_branch_unlikely(_slb_key);
 }
 
+void slb_setup_new_exec(void);
+
 #endif /* ARCH_POWERPC_MM_BOOK3S64_INTERNAL_H */
diff --git a/arch/powerpc/mm/book3s64/mmu_context.c 
b/arch/powerpc/mm/book3s64/mmu_context.c
index 0ba30b8b935b..1c54821de7bf 100644
--- a/arch/powerpc/mm/book3s64/mmu_context.c
+++ b/arch/powerpc/mm/book3s64/mmu_context.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 static DEFINE_IDA(mmu_context_ida);
 
 static int alloc_context_id(int min_id, int max_id)
@@ -48,8 +50,6 @@ int hash__alloc_context_id(void)
 }
 EXPORT_SYMBOL_GPL(hash__alloc_context_id);
 
-void slb_setup_new_exec(void);
-
 static int realloc_context_ids(mm_context_t *ctx)
 {
int i, id;
-- 
2.25.1



[PATCH 2/2] powerpc/perf: Add declarations to fix sparse warnings

2020-09-16 Thread Michael Ellerman
Sparse warns about all the init functions:
  symbol init_ppc970_pmu was not declared. Should it be static?
  symbol init_power5p_pmu was not declared. Should it be static?
  symbol init_power5_pmu was not declared. Should it be static?
  symbol init_power6_pmu was not declared. Should it be static?
  symbol init_power7_pmu was not declared. Should it be static?
  symbol init_power9_pmu was not declared. Should it be static?
  symbol init_power8_pmu was not declared. Should it be static?
  symbol init_generic_compat_pmu was not declared. Should it be static?

They're already declared in internal.h, so just make sure all the C
files include that directly or indirectly.

Signed-off-by: Michael Ellerman 
---
 arch/powerpc/perf/isa207-common.h | 2 ++
 arch/powerpc/perf/power10-pmu.c   | 1 -
 arch/powerpc/perf/power5+-pmu.c   | 2 ++
 arch/powerpc/perf/power5-pmu.c| 2 ++
 arch/powerpc/perf/power6-pmu.c| 2 ++
 arch/powerpc/perf/power7-pmu.c| 2 ++
 arch/powerpc/perf/ppc970-pmu.c| 2 ++
 7 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/perf/isa207-common.h 
b/arch/powerpc/perf/isa207-common.h
index 044de65e96b9..7025de5e60e7 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 #define EVENT_EBB_MASK 1ull
 #define EVENT_EBB_SHIFTPERF_EVENT_CONFIG_EBB_SHIFT
 #define EVENT_BHRB_MASK1ull
diff --git a/arch/powerpc/perf/power10-pmu.c b/arch/powerpc/perf/power10-pmu.c
index 83148656b524..9dbe8f9b89b4 100644
--- a/arch/powerpc/perf/power10-pmu.c
+++ b/arch/powerpc/perf/power10-pmu.c
@@ -9,7 +9,6 @@
 #define pr_fmt(fmt)"power10-pmu: " fmt
 
 #include "isa207-common.h"
-#include "internal.h"
 
 /*
  * Raw event encoding for Power10:
diff --git a/arch/powerpc/perf/power5+-pmu.c b/arch/powerpc/perf/power5+-pmu.c
index a62b2cd7914f..3e64b4a1511f 100644
--- a/arch/powerpc/perf/power5+-pmu.c
+++ b/arch/powerpc/perf/power5+-pmu.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 /*
  * Bits in event code for POWER5+ (POWER5 GS) and POWER5++ (POWER5 GS DD3)
  */
diff --git a/arch/powerpc/perf/power5-pmu.c b/arch/powerpc/perf/power5-pmu.c
index 8732b587cf71..017bb19b73fb 100644
--- a/arch/powerpc/perf/power5-pmu.c
+++ b/arch/powerpc/perf/power5-pmu.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 /*
  * Bits in event code for POWER5 (not POWER5++)
  */
diff --git a/arch/powerpc/perf/power6-pmu.c b/arch/powerpc/perf/power6-pmu.c
index 0e318cf87129..189974478e9f 100644
--- a/arch/powerpc/perf/power6-pmu.c
+++ b/arch/powerpc/perf/power6-pmu.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 /*
  * Bits in event code for POWER6
  */
diff --git a/arch/powerpc/perf/power7-pmu.c b/arch/powerpc/perf/power7-pmu.c
index 5e0bf09cf077..bacfab104a1a 100644
--- a/arch/powerpc/perf/power7-pmu.c
+++ b/arch/powerpc/perf/power7-pmu.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 /*
  * Bits in event code for POWER7
  */
diff --git a/arch/powerpc/perf/ppc970-pmu.c b/arch/powerpc/perf/ppc970-pmu.c
index d35223fb112c..7d78df97f272 100644
--- a/arch/powerpc/perf/ppc970-pmu.c
+++ b/arch/powerpc/perf/ppc970-pmu.c
@@ -9,6 +9,8 @@
 #include 
 #include 
 
+#include "internal.h"
+
 /*
  * Bits in event code for PPC970
  */
-- 
2.25.1



Re: Injecting SLB miltihit crashes kernel 5.9.0-rc5

2020-09-15 Thread Michael Ellerman
Michal Suchánek  writes:
> Hello,
>
> Using the SLB mutihit injection test module (which I did not write so I
> do not want to post it here) to verify updates on my 5.3 frankernekernel
> I found that the kernel crashes with Oops: kernel bad access.
>
> I tested on latest upstream kernel build that I have at hand and the
> result is te same (minus the message - nothing was logged and the kernel
> simply rebooted).

That's disappointing.

> Since the whole effort to write a real mode MCE handler was supposed to
> prevent this maybe the SLB injection module should be added to the
> kernel selftests?

Yes I'd like to see it upstream. I think it should be integrated into
LKDTM, which contains other dangerous things like that and is designed
for testing how the kernel handles/recovers from bad conditions.

cheers


Re: [PATCH 00/15] selftests/seccomp: Refactor change_syscall()

2020-09-15 Thread Michael Ellerman
Kees Cook  writes:
> On Mon, Sep 14, 2020 at 10:15:18PM +1000, Michael Ellerman wrote:
>> Kees Cook  writes:
>> > Hi,
>> >
>> > This refactors the seccomp selftest macros used in change_syscall(),
>> > in an effort to remove special cases for mips, arm, arm64, and xtensa,
>> > which paves the way for powerpc fixes.
>> >
>> > I'm not entirely done testing, but all-arch build tests and x86_64
>> > selftests pass. I'll be doing arm, arm64, and i386 selftests shortly,
>> > but I currently don't have an easy way to check xtensa, mips, nor
>> > powerpc. Any help there would be appreciated!
>> 
>> The series builds fine for me, and all the tests pass (see below).
>> 
>> Thanks for picking up those changes to deal with powerpc being oddball.
>> 
>> Tested-by: Michael Ellerman  (powerpc)
>
> Awesome; thanks!
>
> However...
>
>> ./seccomp_bpf
>> TAP version 13
>> 1..86
>> # Starting 86 tests from 7 test cases.
>> #  RUN   global.kcmp ...
>> #OK  global.kcmp
>> ok 1 global.kcmp
>> [...]
>> #  RUN   global.KILL_thread ...
>> TAP version 13
>> 1..86
>> # Starting 86 tests from 7 test cases.
>
> Was this a mis-paste, or has something very very bad happened here in
> global.KILL_one_arg_six finishes?
>
...
>> TAP version 13
>> 1..86
>> # Starting 86 tests from 7 test cases.
>> [...]
>> # PASSED: 86 / 86 tests passed.
>> # Totals: pass:86 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> And after every user_notification test? O_O

Haha, I thought that was normal :)

It's because of redirection, I run the tests with:

  find . -executable -type f -print -execdir '{}' ';' | tee test.log

If I just run it directly on the terminal everything is normal.

It'll be fork() vs libc buffering.

I can fix it with:

$ stdbuf -oL ./seccomp_bpf | tee test.log

Or the patch below.

I can send a proper patch for that tomorrow, I don't know that harness
code, but I think that's the right fix.

cheers


diff --git a/tools/testing/selftests/kselftest_harness.h 
b/tools/testing/selftests/kselftest_harness.h
index 4f78e4805633..b1bd00ff3d94 100644
--- a/tools/testing/selftests/kselftest_harness.h
+++ b/tools/testing/selftests/kselftest_harness.h
@@ -971,6 +971,7 @@ void __run_test(struct __fixture_metadata *f,
 
ksft_print_msg(" RUN   %s%s%s.%s ...\n",
   f->name, variant->name[0] ? "." : "", variant->name, t->name);
+   fflush(stdout);
t->pid = fork();
if (t->pid < 0) {
ksft_print_msg("ERROR SPAWNING TEST CHILD\n");


Re: [PATCH v2] powerpc/papr_scm: Fix warning triggered by perf_stats_show()

2020-09-15 Thread Michael Ellerman
Vaibhav Jain  writes:
> A warning is reported by the kernel in case perf_stats_show() returns
> an error code. The warning is of the form below:
>
>  papr_scm ibm,persistent-memory:ibm,pmemory@4411:
> Failed to query performance stats, Err:-10
>  dev_attr_show: perf_stats_show+0x0/0x1c0 [papr_scm] returned bad count
>  fill_read_buffer: dev_attr_show+0x0/0xb0 returned bad count
>
> On investigation it looks like that the compiler is silently truncating the
> return value of drc_pmem_query_stats() from 'long' to 'int', since the
> variable used to store the return code 'rc' is an 'int'. This
> truncated value is then returned back as a 'ssize_t' back from
> perf_stats_show() to 'dev_attr_show()' which thinks of it as a large
> unsigned number and triggers this warning..
>
> To fix this we update the type of variable 'rc' from 'int' to
> 'ssize_t' that prevents the compiler from truncating the return value
> of drc_pmem_query_stats() and returning correct signed value back from
> perf_stats_show().
>
> Fixes: 2d02bf835e573 ('powerpc/papr_scm: Fetch nvdimm performance
>stats from PHYP')

Please don't word wrap the Fixes tag it breaks b4.

I've fixed it up this time.

cheers


Re: [PATCH v2 1/4] mm: fix exec activate_mm vs TLB shootdown and lazy tlb switching race

2020-09-15 Thread Michael Ellerman
Nicholas Piggin  writes:
> Excerpts from pet...@infradead.org's message of September 14, 2020 8:56 pm:
>> On Mon, Sep 14, 2020 at 02:52:16PM +1000, Nicholas Piggin wrote:
>>> Reading and modifying current->mm and current->active_mm and switching
>>> mm should be done with irqs off, to prevent races seeing an intermediate
>>> state.
...
>>> 
>>> Signed-off-by: Nicholas Piggin 
>> 
>> Acked-by: Peter Zijlstra (Intel) 
>> 
>> I'm thinking we want this selected on x86 as well. Andy?
>
> Thanks for the ack. The plan was to take it through the powerpc tree,
> but if you'd want x86 to select it, maybe a topic branch? Although
> Michael will be away during the next merge window so I don't want to
> get too fancy. Would you mind doing it in a follow up merge after
> powerpc, being that it's (I think) a small change?

Or get akpm to take the series, including the x86 change.

cheers


Re: [5.9.0-rc5-20200914] Kernel crash while running LTP(mlock201)

2020-09-15 Thread Michael Ellerman
Sachin Sant  writes:
> While running LTP tests (specifically mlock201) against next-20200914 tree
> on a POWER9 LPAR results in following crash.

Looks the same as:

https://lore.kernel.org/linux-mm/20200914085545.GB28738@shao2-debian/

cheers

> BUG: Kernel NULL pointer dereference on read at 0x
> Faulting instruction address: 0xc0454248
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
> Modules linked in: af_packet(E) nft_ct(E) nf_conntrack(E) nf_defrag_ipv6(E) 
> nf_defrag_ipv4(E) libcrc32c(E) ip6_tables(E) nft_compat(E) ip_set(E) 
> rfkill(E) nf_tables(E) nfnetlink(E) vmx_crypto(E) uio_pdrv_genirq(E) 
> gf128mul(E) uio(E) rtc_generic(E) crct10dif_vpmsum(E) sch_fq_codel(E) 
> ip_tables(E) x_tables(E) ext4(E) crc16(E) mbcache(E) jbd2(E) sd_mod(E) 
> t10_pi(E) sg(E) ibmvscsi(E) scsi_transport_srp(E) scsi_mod(E) ibmveth(E) 
> crc32c_vpmsum(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) autofs4(E)
> CPU: 11 PID: 26435 Comm: mlock201 Tainted: GE 
> 5.9.0-rc5-next-20200914-281.gf529200-default #1
> NIP:  c0454248 LR: c0445a74 CTR: c0413150
> REGS: c008e645b770 TRAP: 0300   Tainted: GE  
> (5.9.0-rc5-next-20200914-281.gf529200-default)
> MSR:  80009033   CR: 28002482  XER: 2004
> CFAR: c000fbb0 DAR:  DSISR: 4000 IRQMASK: 0 
> GPR00: c0445a74 c008e645ba00 c17c4500  
> GPR04: 0001 c008ea109e98 c008f0c4  
> GPR08:    0003 
> GPR12: c0413150 c0001ec70200  c1502038 
> GPR16: 7fff9c61 7fff9c61 7fff9c61 c0cb02f8 
> GPR20: 7fff9c5c 7fff9c62 c008e645bcd8 c008f0c4 
> GPR24: c00c023c0d00 fe7f  c008f0c4 
> GPR28: c008ea109e98 0001 c008ea9288a8  
> NIP [c0454248] PageHuge+0x8/0x60
> LR [c0445a74] find_get_incore_page+0x114/0x160
> Call Trace:
> [c008e645ba00] [c0445994] find_get_incore_page+0x34/0x160 
> (unreliable)
> [c008e645ba40] [c0412e54] mincore_page+0x24/0x160
> [c008e645ba70] [c0413020] __mincore_unmapped_range+0x90/0x160
> [c008e645bac0] [c0413680] mincore_pte_range+0x530/0x5d0
> [c008e645bb40] [c0422a38] walk_pgd_range+0x4e8/0xae0
> [c008e645bc30] [c04230c4] __walk_page_range+0x94/0x250
> [c008e645bcb0] [c04233d8] walk_page_range+0x158/0x1e0
> [c008e645bd40] [c041386c] sys_mincore+0x14c/0x370
> [c008e645bdc0] [c0033eb8] system_call_exception+0xf8/0x200
> [c008e645be20] [c000d140] system_call_common+0xf0/0x27c
> Instruction dump:
> e8410018 38210020 e8010010 7c0803a6 4e800020 6000 3d41 7d435378 
> 4e800020 6000 7c0802a6 6000  75290001 40820010 e9230008 
> ---[ end trace 357eb14a3b22eab2 ]—
>
>
> The function find_get_incore_page() was introduced with 
> 3fcbe4eb49a0406e6202e8c8c3560f30965a8e79 
>
> mm: factor find_get_incore_page out of mincore_page
>
>
> Thanks
> -Sachin


Re: [PATCH 00/15] selftests/seccomp: Refactor change_syscall()

2020-09-14 Thread Michael Ellerman
Kees Cook  writes:
> Hi,
>
> This refactors the seccomp selftest macros used in change_syscall(),
> in an effort to remove special cases for mips, arm, arm64, and xtensa,
> which paves the way for powerpc fixes.
>
> I'm not entirely done testing, but all-arch build tests and x86_64
> selftests pass. I'll be doing arm, arm64, and i386 selftests shortly,
> but I currently don't have an easy way to check xtensa, mips, nor
> powerpc. Any help there would be appreciated!

The series builds fine for me, and all the tests pass (see below).

Thanks for picking up those changes to deal with powerpc being oddball.

Tested-by: Michael Ellerman  (powerpc)

cheers


./seccomp_bpf
TAP version 13
1..86
# Starting 86 tests from 7 test cases.
#  RUN   global.kcmp ...
#OK  global.kcmp
ok 1 global.kcmp
#  RUN   global.mode_strict_support ...
#OK  global.mode_strict_support
ok 2 global.mode_strict_support
#  RUN   global.mode_strict_cannot_call_prctl ...
#OK  global.mode_strict_cannot_call_prctl
ok 3 global.mode_strict_cannot_call_prctl
#  RUN   global.no_new_privs_support ...
#OK  global.no_new_privs_support
ok 4 global.no_new_privs_support
#  RUN   global.mode_filter_support ...
#OK  global.mode_filter_support
ok 5 global.mode_filter_support
#  RUN   global.mode_filter_without_nnp ...
#OK  global.mode_filter_without_nnp
ok 6 global.mode_filter_without_nnp
#  RUN   global.filter_size_limits ...
#OK  global.filter_size_limits
ok 7 global.filter_size_limits
#  RUN   global.filter_chain_limits ...
#OK  global.filter_chain_limits
ok 8 global.filter_chain_limits
#  RUN   global.mode_filter_cannot_move_to_strict ...
#OK  global.mode_filter_cannot_move_to_strict
ok 9 global.mode_filter_cannot_move_to_strict
#  RUN   global.mode_filter_get_seccomp ...
#OK  global.mode_filter_get_seccomp
ok 10 global.mode_filter_get_seccomp
#  RUN   global.ALLOW_all ...
#OK  global.ALLOW_all
ok 11 global.ALLOW_all
#  RUN   global.empty_prog ...
#OK  global.empty_prog
ok 12 global.empty_prog
#  RUN   global.log_all ...
#OK  global.log_all
ok 13 global.log_all
#  RUN   global.unknown_ret_is_kill_inside ...
#OK  global.unknown_ret_is_kill_inside
ok 14 global.unknown_ret_is_kill_inside
#  RUN   global.unknown_ret_is_kill_above_allow ...
#OK  global.unknown_ret_is_kill_above_allow
ok 15 global.unknown_ret_is_kill_above_allow
#  RUN   global.KILL_all ...
#OK  global.KILL_all
ok 16 global.KILL_all
#  RUN   global.KILL_one ...
#OK  global.KILL_one
ok 17 global.KILL_one
#  RUN   global.KILL_one_arg_one ...
#OK  global.KILL_one_arg_one
ok 18 global.KILL_one_arg_one
#  RUN   global.KILL_one_arg_six ...
#OK  global.KILL_one_arg_six
ok 19 global.KILL_one_arg_six
#  RUN   global.KILL_thread ...
TAP version 13
1..86
# Starting 86 tests from 7 test cases.
#  RUN   global.kcmp ...
#OK  global.kcmp
ok 1 global.kcmp
#  RUN   global.mode_strict_support ...
#OK  global.mode_strict_support
ok 2 global.mode_strict_support
#  RUN   global.mode_strict_cannot_call_prctl ...
#OK  global.mode_strict_cannot_call_prctl
ok 3 global.mode_strict_cannot_call_prctl
#  RUN   global.no_new_privs_support ...
#OK  global.no_new_privs_support
ok 4 global.no_new_privs_support
#  RUN   global.mode_filter_support ...
#OK  global.mode_filter_support
ok 5 global.mode_filter_support
#  RUN   global.mode_filter_without_nnp ...
#OK  global.mode_filter_without_nnp
ok 6 global.mode_filter_without_nnp
#  RUN   global.filter_size_limits ...
#OK  global.filter_size_limits
ok 7 global.filter_size_limits
#  RUN   global.filter_chain_limits ...
#OK  global.filter_chain_limits
ok 8 global.filter_chain_limits
#  RUN   global.mode_filter_cannot_move_to_strict ...
#OK  global.mode_filter_cannot_move_to_strict
ok 9 global.mode_filter_cannot_move_to_strict
#  RUN   global.mode_filter_get_seccomp ...
#OK  global.mode_filter_get_seccomp
ok 10 global.mode_filter_get_seccomp
#  RUN   global.ALLOW_all ...
#OK  global.ALLOW_all
ok 11 global.ALLOW_all
#  RUN   global.empty_prog ...
#OK  global.empty_prog
ok 12 global.empty_prog
#  RUN   global.log_all ...
#OK  global.log_all
ok 13 global.log_all
#  RUN   global.unknown_ret_is_kill_inside ...
#OK  global.unknown_ret_is_kill_inside
ok 14 global.unknown_ret_is_kill_inside
#  RUN   global.unknown_ret_is_kill_above_allow ...
#OK  global.unknown

Re: [PATCH 13/15] selftests/seccomp: powerpc: Set syscall return during ptrace syscall exit

2020-09-13 Thread Michael Ellerman
Kees Cook  writes:
> Some archs (like ppc) only support changing the return code during
> syscall exit when ptrace is used. As the syscall number might not
> be available anymore during syscall exit, it needs to be saved
> during syscall enter. Adjust the ptrace tests to do this.

I'm not that across all the fixture stuff, but if I'm reading it right
you're now calling change_syscall() on both entry and exit for all
arches.

That should work, but it no longer tests changing the return code on
entry on the arches that support it, which seems like a backward step?

cheers


> Reported-by: Thadeu Lima de Souza Cascardo 
> Suggested-by: Thadeu Lima de Souza Cascardo 
> Link: 
> https://lore.kernel.org/linux-kselftest/20200911181012.171027-1-casca...@canonical.com/
> Fixes: 58d0a862f573 ("seccomp: add tests for ptrace hole")
> Signed-off-by: Kees Cook 
> ---
>  tools/testing/selftests/seccomp/seccomp_bpf.c | 34 +++
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c 
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index bbab2420d708..26c712c6a575 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -1949,12 +1949,19 @@ void tracer_seccomp(struct __test_metadata 
> *_metadata, pid_t tracee,
>  
>  }
>  
> +FIXTURE(TRACE_syscall) {
> + struct sock_fprog prog;
> + pid_t tracer, mytid, mypid, parent;
> + long syscall_nr;
> +};
> +
>  void tracer_ptrace(struct __test_metadata *_metadata, pid_t tracee,
>  int status, void *args)
>  {
> - int ret, nr;
> + int ret;
>   unsigned long msg;
>   static bool entry;
> + FIXTURE_DATA(TRACE_syscall) *self = args;
>  
>   /*
>* The traditional way to tell PTRACE_SYSCALL entry/exit
> @@ -1968,24 +1975,23 @@ void tracer_ptrace(struct __test_metadata *_metadata, 
> pid_t tracee,
>   EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
>   : PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
>  
> - if (!entry)
> - return;
> -
> - nr = get_syscall(_metadata, tracee);
> + /*
> +  * Some architectures only support setting return values during
> +  * syscall exit under ptrace, and on exit the syscall number may
> +  * no longer be available. Therefore, save it here, and call
> +  * "change syscall and set return values" on both entry and exit.
> +  */
> + if (entry)
> + self->syscall_nr = get_syscall(_metadata, tracee);
>  
> - if (nr == __NR_getpid)
> + if (self->syscall_nr == __NR_getpid)
>   change_syscall(_metadata, tracee, __NR_getppid, 0);
> - if (nr == __NR_gettid)
> + if (self->syscall_nr == __NR_gettid)
>   change_syscall(_metadata, tracee, -1, 45000);
> - if (nr == __NR_openat)
> + if (self->syscall_nr == __NR_openat)
>   change_syscall(_metadata, tracee, -1, -ESRCH);
>  }
>  
> -FIXTURE(TRACE_syscall) {
> - struct sock_fprog prog;
> - pid_t tracer, mytid, mypid, parent;
> -};
> -
>  FIXTURE_VARIANT(TRACE_syscall) {
>   /*
>* All of the SECCOMP_RET_TRACE behaviors can be tested with either
> @@ -2044,7 +2050,7 @@ FIXTURE_SETUP(TRACE_syscall)
>   self->tracer = setup_trace_fixture(_metadata,
>  variant->use_ptrace ? tracer_ptrace
>  : tracer_seccomp,
> -NULL, variant->use_ptrace);
> +self, variant->use_ptrace);
>  
>   ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
>   ASSERT_EQ(0, ret);
> -- 
> 2.25.1


Re: [PATCH 12/15] selftests/seccomp: powerpc: Fix seccomp return value testing

2020-09-13 Thread Michael Ellerman
Kees Cook  writes:
> On powerpc, the errno is not inverted, and depends on ccr.so being
> set. Add this to a powerpc definition of SYSCALL_RET_SET().
>
> Co-developed-by: Thadeu Lima de Souza Cascardo 
> Signed-off-by: Thadeu Lima de Souza Cascardo 
> Link: 
> https://lore.kernel.org/linux-kselftest/20200911181012.171027-1-casca...@canonical.com/
> Fixes: 5d83c2b37d43 ("selftests/seccomp: Add powerpc support")
> Signed-off-by: Kees Cook 
> ---
>  tools/testing/selftests/seccomp/seccomp_bpf.c | 15 +++
>  1 file changed, 15 insertions(+)

This looks right to me, and matches what strace does AFAICS.

Reviewed-by: Michael Ellerman 

cheers

> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c 
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 623953a53032..bbab2420d708 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -1750,6 +1750,21 @@ TEST_F(TRACE_poke, getpid_runs_normally)
>  # define ARCH_REGS   struct pt_regs
>  # define SYSCALL_NUM(_regs)  (_regs).gpr[0]
>  # define SYSCALL_RET(_regs)  (_regs).gpr[3]
> +# define SYSCALL_RET_SET(_regs, _val)\
> + do {\
> + typeof(_val) _result = (_val);  \
> + /*  \
> +  * A syscall error is signaled by CR0 SO bit\
> +  * and the code is stored as a positive value.  \
> +  */ \
> + if (_result < 0) {  \
> + SYSCALL_RET(_regs) = -result;   \
> + (_regs).ccr |= 0x1000;  \
> + } else {\
> + SYSCALL_RET(_regs) = result;\
> + (_regs).ccr &= ~0x1000; \
> + }   \
> + } while (0)
>  #elif defined(__s390__)
>  # define ARCH_REGS   s390_regs
>  # define SYSCALL_NUM(_regs)  (_regs).gprs[2]
> -- 
> 2.25.1


Re: [PATCH] selftests/seccomp: fix ptrace tests on powerpc

2020-09-13 Thread Michael Ellerman
Thadeu Lima de Souza Cascardo  writes:
> On Tue, Sep 08, 2020 at 04:18:17PM -0700, Kees Cook wrote:
>> On Tue, Jun 30, 2020 at 01:47:39PM -0300, Thadeu Lima de Souza Cascardo 
>> wrote:
...
>> > @@ -1809,10 +1818,15 @@ void tracer_ptrace(struct __test_metadata 
>> > *_metadata, pid_t tracee,
>> >EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
>> >: PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
>> >  
>> > -  if (!entry)
>> > +  if (!entry && !syscall_nr)
>> >return;
>> >  
>> > -  nr = get_syscall(_metadata, tracee);
>> > +  if (entry)
>> > +  nr = get_syscall(_metadata, tracee);
>> > +  else
>> > +  nr = *syscall_nr;
>> 
>> This is weird? Shouldn't get_syscall() be modified to do the right thing
>> here instead of depending on the extra arg?
>> 
>
> R0 might be clobered. Same documentation mentions it as volatile. So, during
> syscall exit, we can't tell for sure that R0 will have the original syscall
> number. So, we need to grab it during syscall enter, save it somewhere and
> reuse it. I used the test context/args for that.

The user r0 (in regs->gpr[0]) shouldn't be clobbered.

But it is modified if the tracer skips the syscall, by setting the
syscall number to -1. Or if the tracer changes the syscall number.

So if you need the original syscall number in the exit path then I think
you do need to save it at entry.

cheers


Re: [PATCH v2] selftests/seccomp: fix ptrace tests on powerpc

2020-09-13 Thread Michael Ellerman
Kees Cook  writes:
> On Fri, Sep 11, 2020 at 03:10:12PM -0300, Thadeu Lima de Souza Cascardo wrote:
...
>> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c 
>> b/tools/testing/selftests/seccomp/seccomp_bpf.c
>> index 7a6d40286a42..0ddc0846e9c0 100644
>> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
>> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
>> @@ -1916,10 +1957,15 @@ void tracer_ptrace(struct __test_metadata 
>> *_metadata, pid_t tracee,
>>  EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
>>  : PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
>>  
>> -if (!entry)
>> +if (!entry && !variant)
>>  return;
>>  
>> -nr = get_syscall(_metadata, tracee);
>> +if (entry)
>> +nr = get_syscall(_metadata, tracee);
>> +else if (variant)
>> +nr = variant->syscall_nr;
>> +if (variant)
>> +variant->syscall_nr = nr;
>
> So, to be clear this is _only_ an issue for the ptrace side of things,
> yes? i.e. seccomp's setting of the return value will correct stick?

Yes. There's a comment which (hopefully) explains the difference here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/ptrace/ptrace.c?commit=ab29a807a7ddaa7c84d2f4cb8d29e74e33759072#n239

Which says:

static int do_seccomp(struct pt_regs *regs)
{
if (!test_thread_flag(TIF_SECCOMP))
return 0;

/*
 * The ABI we present to seccomp tracers is that r3 contains
 * the syscall return value and orig_gpr3 contains the first
 * syscall parameter. This is different to the ptrace ABI where
 * both r3 and orig_gpr3 contain the first syscall parameter.
 */
regs->gpr[3] = -ENOSYS;


cheers


Re: [PATCH v5 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

2020-09-12 Thread Michael Ellerman
Srikar Dronamraju  writes:
> * Michael Ellerman  [2020-09-11 21:55:23]:
>
>> Srikar Dronamraju  writes:
>> > Current code assumes that cpumask of cpus sharing a l2-cache mask will
>> > always be a superset of cpu_sibling_mask.
>> >
>> > Lets stop that assumption. cpu_l2_cache_mask is a superset of
>> > cpu_sibling_mask if and only if shared_caches is set.
>> 
>> I'm seeing oopses with this:
>> 
>> [0.117392][T1] smp: Bringing up secondary CPUs ...
>> [0.156515][T1] smp: Brought up 2 nodes, 2 CPUs
>> [0.158265][T1] numa: Node 0 CPUs: 0
>> [0.158520][T1] numa: Node 1 CPUs: 1
>> [0.167453][T1] BUG: Unable to handle kernel data access on read at 
>> 0x800041228298
>> [0.167992][T1] Faulting instruction address: 0xc018c128
>> [0.168817][T1] Oops: Kernel access of bad area, sig: 11 [#1]
>> [0.168964][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA 
>> pSeries
>> [0.169417][T1] Modules linked in:
>> [0.170047][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
>> 5.9.0-rc2-00095-g7430ad5aa700 #209
>> [0.170305][T1] NIP:  c018c128 LR: c018c0cc CTR: 
>> c004dce0
>> [0.170498][T1] REGS: c0007e343880 TRAP: 0380   Not tainted  
>> (5.9.0-rc2-00095-g7430ad5aa700)
>> [0.170602][T1] MSR:  82009033   
>> CR: 4400  XER: 
>> [0.170985][T1] CFAR: c018c288 IRQMASK: 0
>> [0.170985][T1] GPR00:  c0007e343b10 
>> c173e400 4000
>> [0.170985][T1] GPR04:  0800 
>> 0800 
>> [0.170985][T1] GPR08:  c122c298 
>> c0003fffc000 c0007fd05ce8
>> [0.170985][T1] GPR12: c0007e0119f8 c193 
>> 8ade 
>> [0.170985][T1] GPR16: c0007e3c0640 0917 
>> c0007e3c0658 0008
>> [0.170985][T1] GPR20: c15d0bb8 8ade 
>> c0f57400 c1817c28
>> [0.170985][T1] GPR24: c176dc80 c0007e3c0890 
>> c0007e3cfe00 
>> [0.170985][T1] GPR28: c1772310 c0007e011900 
>> c0007e3c0800 0001
>> [0.172750][T1] NIP [c018c128] 
>> build_sched_domains+0x808/0x14b0
>> [0.172900][T1] LR [c018c0cc] build_sched_domains+0x7ac/0x14b0
>> [0.173186][T1] Call Trace:
>> [0.173484][T1] [c0007e343b10] [c018bfe8] 
>> build_sched_domains+0x6c8/0x14b0 (unreliable)
>> [0.173821][T1] [c0007e343c50] [c018dcdc] 
>> sched_init_domains+0xec/0x130
>> [0.174037][T1] [c0007e343ca0] [c10d59d8] 
>> sched_init_smp+0x50/0xc4
>> [0.174207][T1] [c0007e343cd0] [c10b45c4] 
>> kernel_init_freeable+0x1b4/0x378
>> [0.174378][T1] [c0007e343db0] [c00129fc] 
>> kernel_init+0x24/0x158
>> [0.174740][T1] [c0007e343e20] [c000d9d0] 
>> ret_from_kernel_thread+0x5c/0x6c
>> [0.175050][T1] Instruction dump:
>> [0.175626][T1] 554905ee 71480040 7d2907b4 4182016c 2c29 3920006e 
>> 913e002c 41820034
>> [0.175841][T1] 7c6307b4 e9300020 78631f24 7d58182a <7d2a482a> 
>> f93e0080 7d404828 314a0001
>> [0.178340][T1] ---[ end trace 6876b88dd1d4b3bb ]---
>> [0.178512][T1]
>> [1.180458][T1] Kernel panic - not syncing: Attempted to kill init! 
>> exitcode=0x000b
>> 
>> That's qemu:
>> 
>> qemu-system-ppc64 -nographic -vga none -M pseries -cpu POWER8 \
>>   -kernel build~/vmlinux \
>>   -m 2G,slots=2,maxmem=4G \
>>   -object memory-backend-ram,size=1G,id=m0 \
>>   -object memory-backend-ram,size=1G,id=m1 \
>>   -numa node,nodeid=0,memdev=m0 \
>>   -numa node,nodeid=1,memdev=m1 \
>>   -smp 2,sockets=2,maxcpus=2  \
>> 
>
> Thanks Michael for the report and also for identifying the patch and also
> giving an easy reproducer. That made my task easy. (My only problem was all
> my PowerKVM hosts had a old compiler that refuse to compile never kernels.)
>
> So in this setup, CPU doesn't have a l2-cache. And in that scenario, we
> miss updating the l2-cache domain. Actually the initial patch had this
> exact code. However it was my mistake. I should have reassessed it before
> making changes suggested by Gautham.
>
> Patch below. Do let me know if you want me to sen

Re: [PATCH v5 20/23] powerpc/book3s64/hash/kuap: Enable kuap on hash

2020-09-12 Thread Michael Ellerman
"Aneesh Kumar K.V"  writes:
> Signed-off-by: Aneesh Kumar K.V 
> ---
>  arch/powerpc/mm/book3s64/pkeys.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/book3s64/pkeys.c 
> b/arch/powerpc/mm/book3s64/pkeys.c
> index 391230f93da2..16ea0b2f0ea5 100644
> --- a/arch/powerpc/mm/book3s64/pkeys.c
> +++ b/arch/powerpc/mm/book3s64/pkeys.c
> @@ -257,7 +257,12 @@ void __init setup_kuep(bool disabled)
>  #ifdef CONFIG_PPC_KUAP
>  void __init setup_kuap(bool disabled)
>  {
> - if (disabled || !early_radix_enabled())
> + if (disabled)
> + return;
> + /*
> +  * On hash if PKEY feature is not enabled, disable KUAP too.
> +  */
> + if (!early_radix_enabled() && !early_mmu_has_feature(MMU_FTR_PKEY))
>   return;
>  
>   if (smp_processor_id() == boot_cpuid) {

I'm seeing userspace crashes, bisect points at this commit. But
obviously this is just the commit that enables the code.

It seems to be TM related, a lot of the TM selftests are failing with
seemingly random segfaults.

eg:

  ./tm-tmspr
  test: tm_tmspr
  tags: git_version:v5.9-rc2-146-g928c664a7f4e
  !! child died by signal 11
  failure: tm_tmspr

And this warning fires:

  [  308.825455] [ cut here ]
  [  308.825485] WARNING: CPU: 5 PID: 105478 at 
arch/powerpc/include/asm/book3s/64/kup.h:287 syscall_exit_prepare+0x350/0x390
  [  308.825495] Modules linked in: iptable_mangle xt_MASQUERADE iptable_nat 
nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipt_REJECT 
nf_reject_ipv4 xt_tcpudp tun bridge stp llc ip6table_filter ip6_tables 
iptable_filter fuse kvm_hv kvm binfmt_misc squashfs mlx4_ib ib_uverbs 
dm_multipath scsi_dh_rdac scsi_dh_alua ib_core mlx4_en bnx2x lpfc mlx4_core 
crc_t10dif sr_mod crct10dif_generic cdrom vmx_crypto scsi_transport_fc sg mdio 
gf128mul crct10dif_vpmsum crct10dif_common powernv_rng crc32c_vpmsum rng_core 
leds_powernv powernv_op_panel led_class sunrpc ip_tables x_tables autofs4
  [  308.825596] CPU: 5 PID: 105478 Comm: tm-tmspr Tainted: P  
5.9.0-rc2-00146-g928c664a7f4e #1
  [  308.825607] NIP:  c0038640 LR: c000ddcc CTR: 
c03c32d0
  [  308.825616] REGS: c01e41877b00 TRAP: 0700   Tainted: P 
  (5.9.0-rc2-00146-g928c664a7f4e)
  [  308.825625] MSR:  90010282b033 
  CR: 44004484  XER: 2000
  [  308.825649] CFAR: c0038358 IRQMASK: 0 
 GPR00: c000ddcc c01e41877da0 c143f000 
 
 GPR04: c01e41877e80  7ffec6ed 
0008 
 GPR08: 0002 3cff fcff 
f5638000 
 GPR12: 4400 c007a680  
77ff 
 GPR16: 77f54410 77f50320 7ffec6eff240 
77f54420 
 GPR20: 04ba 000116c0 000100034840 
 
 GPR24:  7ffec6eff8f0  
7ffec6efea80 
 GPR28: 738f c01e2e05d600 7ffec6eff180 
c01e41877e80 
  [  308.825724] NIP [c0038640] syscall_exit_prepare+0x350/0x390
  [  308.825734] LR [c000ddcc] system_call_common+0xfc/0x27c
  [  308.825741] Call Trace:
  [  308.825751] [c01e41877da0] [c01e41877e10] 0xc01e41877e10 
(unreliable)
  [  308.825763] [c01e41877e10] [c000ddcc] 
system_call_common+0xfc/0x27c
  [  308.825771] Instruction dump:
  [  308.825778] 713c0800 4082004c f87f0018 395d0080 39001800 7ce050a8 7ce74078 
7ce051ad 
  [  308.825794] 40c2fff4 4bfffd54 6000 6000 <0fe0> 4bfffd18 
6000 6000 
  [  308.825811] ---[ end trace 57dae589ab37c54c ]---


That's on power8, both bare metal and LPAR.

cheers


Re: [PATCH] powerpc/traps: fix recoverability of machine check handling on book3s/32

2020-09-11 Thread Michael Ellerman
Michal Suchánek  writes:
> Hello,
>
> does this logic apply to "Unrecoverable System Reset" as well?

Which logic do you mean?

We do call die() before checking MSR_RI in system_reset_exception():

/*
 * No debugger or crash dump registered, print logs then
 * panic.
 */
die("System Reset", regs, SIGABRT);
  
mdelay(2*MSEC_PER_SEC); /* Wait a little while for others to print */
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
nmi_panic(regs, "System Reset");
  
  out:
  #ifdef CONFIG_PPC_BOOK3S_64
BUG_ON(get_paca()->in_nmi == 0);
if (get_paca()->in_nmi > 1)
die("Unrecoverable nested System Reset", regs, SIGABRT);
  #endif
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
die("Unrecoverable System Reset", regs, SIGABRT);


So you should see the output from die("System Reset", ...) even if
MSR[RI] was clear when you took the system reset.

cheers

> On Tue, Jan 22, 2019 at 02:11:24PM +, Christophe Leroy wrote:
>> Looks like book3s/32 doesn't set RI on machine check, so
>> checking RI before calling die() will always be fatal
>> allthought this is not an issue in most cases.
>> 
>> Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable 
>> interrupt")
>> Fixes: daf00ae71dad ("powerpc/traps: restore recoverability of machine_check 
>> interrupts")
>> Signed-off-by: Christophe Leroy 
>> Cc: sta...@vger.kernel.org
>> ---
>>  arch/powerpc/kernel/traps.c | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>> index 64936b60d521..c740f8bfccc9 100644
>> --- a/arch/powerpc/kernel/traps.c
>> +++ b/arch/powerpc/kernel/traps.c
>> @@ -763,15 +763,15 @@ void machine_check_exception(struct pt_regs *regs)
>>  if (check_io_access(regs))
>>  goto bail;
>>  
>> -/* Must die if the interrupt is not recoverable */
>> -if (!(regs->msr & MSR_RI))
>> -nmi_panic(regs, "Unrecoverable Machine check");
>> -
>>  if (!nested)
>>  nmi_exit();
>>  
>>  die("Machine check", regs, SIGBUS);
>>  
>> +/* Must die if the interrupt is not recoverable */
>> +if (!(regs->msr & MSR_RI))
>> +nmi_panic(regs, "Unrecoverable Machine check");
>> +
>>  return;
>>  
>>  bail:
>> -- 
>> 2.13.3
>> 


Re: [PATCH v1] pseries/hotplug-memory: hot-add: skip redundant LMB lookup

2020-09-11 Thread Michael Ellerman
Hi Scott,

Scott Cheloha  writes:
> During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
> to determine which node id (nid) to use when later calling __add_memory().
>
...
>
> Consider an LPAR with 126976 LMBs.  In one test, hot-adding 126000

Nice little machine you got there :P

> LMBs on an upatched kernel took ~3.5 hours while a patched kernel
> completed the same operation in ~2 hours:

...

> diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
> b/arch/powerpc/platforms/pseries/hotplug-memory.c
> index 0ea976d1cac4..9cd572440175 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> @@ -595,6 +595,8 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, 
> u32 drc_index)
>  }
>  #endif /* CONFIG_MEMORY_HOTREMOVE */
>  
> +extern int of_drconf_to_nid_single(struct drmem_lmb *);
> +

This needs to go in a header.

It should probably go in arch/powerpc/include/asm/topology.h

cheers

>  static int dlpar_add_lmb(struct drmem_lmb *lmb)
>  {
>   unsigned long block_sz;
> @@ -611,8 +613,10 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
>  
>   block_sz = memory_block_size_bytes();
>  
> - /* Find the node id for this address. */
> - nid = memory_add_physaddr_to_nid(lmb->base_addr);
> + /* Find the node id for this address.  Fake one if necessary. */
> + nid = of_drconf_to_nid_single(lmb);
> + if (nid < 0 || !node_possible(nid))
> + nid = first_online_node;
>  
>   /* Add the memory */
>   rc = __add_memory(nid, lmb->base_addr, block_sz);
> -- 
> 2.24.1


Re: [PATCH] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP

2020-09-11 Thread Michael Ellerman
Christophe Leroy  writes:
> Le 11/09/2020 à 01:56, Michael Ellerman a écrit :
>> Christophe Leroy  writes:
>>> low_sleep_handler() has an hardcoded restore of segment registers
>>> that doesn't take KUAP and KUEP into account.
>>>
>>> Use head_32's load_segment_registers() routine instead.
>>>
>>> Signed-off-by: Christophe Leroy 
>>> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access 
>>> Protection")
>>> Fixes: 31ed2b13c48d ("powerpc/32s: Implement Kernel Userspace Execution 
>>> Prevention.")
>>> Cc: sta...@vger.kernel.org
>>> ---
>>>   arch/powerpc/platforms/powermac/sleep.S | 9 +
>>>   1 file changed, 1 insertion(+), 8 deletions(-)
>> 
>> Doesn't build? pmac32_defconfig, gcc 9.3.0:
>> 
>> ld: arch/powerpc/platforms/powermac/sleep.o: in function `core99_wake_up':
>> (.text+0x25c): undefined reference to `load_segment_registers'
>> 
>> Missing _GLOBAL() presumably?
>
> Oops .. :(
>
> v2 sent out.

Thanks.

cheers


Re: [PATCH v5 05/10] powerpc/smp: Dont assume l2-cache to be superset of sibling

2020-09-11 Thread Michael Ellerman
Srikar Dronamraju  writes:
> Current code assumes that cpumask of cpus sharing a l2-cache mask will
> always be a superset of cpu_sibling_mask.
>
> Lets stop that assumption. cpu_l2_cache_mask is a superset of
> cpu_sibling_mask if and only if shared_caches is set.

I'm seeing oopses with this:

[0.117392][T1] smp: Bringing up secondary CPUs ...
[0.156515][T1] smp: Brought up 2 nodes, 2 CPUs
[0.158265][T1] numa: Node 0 CPUs: 0
[0.158520][T1] numa: Node 1 CPUs: 1
[0.167453][T1] BUG: Unable to handle kernel data access on read at 
0x800041228298
[0.167992][T1] Faulting instruction address: 0xc018c128
[0.168817][T1] Oops: Kernel access of bad area, sig: 11 [#1]
[0.168964][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[0.169417][T1] Modules linked in:
[0.170047][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.9.0-rc2-00095-g7430ad5aa700 #209
[0.170305][T1] NIP:  c018c128 LR: c018c0cc CTR: 
c004dce0
[0.170498][T1] REGS: c0007e343880 TRAP: 0380   Not tainted  
(5.9.0-rc2-00095-g7430ad5aa700)
[0.170602][T1] MSR:  82009033   CR: 
4400  XER: 
[0.170985][T1] CFAR: c018c288 IRQMASK: 0
[0.170985][T1] GPR00:  c0007e343b10 
c173e400 4000
[0.170985][T1] GPR04:  0800 
0800 
[0.170985][T1] GPR08:  c122c298 
c0003fffc000 c0007fd05ce8
[0.170985][T1] GPR12: c0007e0119f8 c193 
8ade 
[0.170985][T1] GPR16: c0007e3c0640 0917 
c0007e3c0658 0008
[0.170985][T1] GPR20: c15d0bb8 8ade 
c0f57400 c1817c28
[0.170985][T1] GPR24: c176dc80 c0007e3c0890 
c0007e3cfe00 
[0.170985][T1] GPR28: c1772310 c0007e011900 
c0007e3c0800 0001
[0.172750][T1] NIP [c018c128] build_sched_domains+0x808/0x14b0
[0.172900][T1] LR [c018c0cc] build_sched_domains+0x7ac/0x14b0
[0.173186][T1] Call Trace:
[0.173484][T1] [c0007e343b10] [c018bfe8] 
build_sched_domains+0x6c8/0x14b0 (unreliable)
[0.173821][T1] [c0007e343c50] [c018dcdc] 
sched_init_domains+0xec/0x130
[0.174037][T1] [c0007e343ca0] [c10d59d8] 
sched_init_smp+0x50/0xc4
[0.174207][T1] [c0007e343cd0] [c10b45c4] 
kernel_init_freeable+0x1b4/0x378
[0.174378][T1] [c0007e343db0] [c00129fc] 
kernel_init+0x24/0x158
[0.174740][T1] [c0007e343e20] [c000d9d0] 
ret_from_kernel_thread+0x5c/0x6c
[0.175050][T1] Instruction dump:
[0.175626][T1] 554905ee 71480040 7d2907b4 4182016c 2c29 3920006e 
913e002c 41820034
[0.175841][T1] 7c6307b4 e9300020 78631f24 7d58182a <7d2a482a> f93e0080 
7d404828 314a0001
[0.178340][T1] ---[ end trace 6876b88dd1d4b3bb ]---
[0.178512][T1]
[1.180458][T1] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x000b

That's qemu:

qemu-system-ppc64 -nographic -vga none -M pseries -cpu POWER8 \
  -kernel build~/vmlinux \
  -m 2G,slots=2,maxmem=4G \
  -object memory-backend-ram,size=1G,id=m0 \
  -object memory-backend-ram,size=1G,id=m1 \
  -numa node,nodeid=0,memdev=m0 \
  -numa node,nodeid=1,memdev=m1 \
  -smp 2,sockets=2,maxcpus=2  \


On mambo I get:

[0.005069][T1] smp: Bringing up secondary CPUs ...
[0.011656][T1] smp: Brought up 2 nodes, 8 CPUs
[0.011682][T1] numa: Node 0 CPUs: 0-3
[0.011709][T1] numa: Node 1 CPUs: 4-7
[0.012015][T1] BUG: arch topology borken
[0.012040][T1]  the SMT domain not a subset of the CACHE domain
[0.012107][T1] BUG: Unable to handle kernel data access on read at 
0x8001012e7398
[0.012142][T1] Faulting instruction address: 0xc01aa4f0
[0.012174][T1] Oops: Kernel access of bad area, sig: 11 [#1]
[0.012206][T1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
[0.012236][T1] Modules linked in:
[0.012264][T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
5.9.0-rc2-00095-g7430ad5aa700 #1
[0.012304][T1] NIP:  c01aa4f0 LR: c01aa498 CTR: 

[0.012341][T1] REGS: c000ef583880 TRAP: 0380   Not tainted  
(5.9.0-rc2-00095-g7430ad5aa700)
[0.012379][T1] MSR:  92009033   
CR: 4400  XER: 0004
[0.012439][T1] CFAR: c00101b0 IRQMASK: 0
[0.012439][T1] GPR00:  c000ef583b10 
c17fd000 4000
[0.012439][T1] GPR04:  0800 
 
[0.012439][T1] GPR08:  c12eb398 
c000c000 

Re: [PATCH] powerpc/powermac: Fix low_sleep_handler with KUAP and KUEP

2020-09-10 Thread Michael Ellerman
Christophe Leroy  writes:
> low_sleep_handler() has an hardcoded restore of segment registers
> that doesn't take KUAP and KUEP into account.
>
> Use head_32's load_segment_registers() routine instead.
>
> Signed-off-by: Christophe Leroy 
> Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access 
> Protection")
> Fixes: 31ed2b13c48d ("powerpc/32s: Implement Kernel Userspace Execution 
> Prevention.")
> Cc: sta...@vger.kernel.org
> ---
>  arch/powerpc/platforms/powermac/sleep.S | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)

Doesn't build? pmac32_defconfig, gcc 9.3.0:

ld: arch/powerpc/platforms/powermac/sleep.o: in function `core99_wake_up':
(.text+0x25c): undefined reference to `load_segment_registers'

Missing _GLOBAL() presumably?

cheers

> diff --git a/arch/powerpc/platforms/powermac/sleep.S 
> b/arch/powerpc/platforms/powermac/sleep.S
> index f9a680fdd9c4..51bfdfe85058 100644
> --- a/arch/powerpc/platforms/powermac/sleep.S
> +++ b/arch/powerpc/platforms/powermac/sleep.S
> @@ -294,14 +294,7 @@ grackle_wake_up:
>* we do any r1 memory access as we are not sure they
>* are in a sane state above the first 256Mb region
>*/
> - li  r0,16   /* load up segment register values */
> - mtctr   r0  /* for context 0 */
> - lis r3,0x2000   /* Ku = 1, VSID = 0 */
> - li  r4,0
> -3:   mtsrin  r3,r4
> - addir3,r3,0x111 /* increment VSID */
> - addis   r4,r4,0x1000/* address of next segment */
> - bdnz3b
> + bl  load_segment_registers
>   sync
>   isync
>  
> -- 
> 2.25.0


Re: [PATCH v2] powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute

2020-09-10 Thread Michael Ellerman
On Mon, 7 Sep 2020 16:35:40 +0530, Vaibhav Jain wrote:
> The newly introduced 'perf_stats' attribute uses the default access
> mode of 0444 letting non-root users access performance stats of an
> nvdimm and potentially force the kernel into issuing large number of
> expensive HCALLs. Since the information exposed by this attribute
> cannot be cached hence its better to ward of access to this attribute
> from users who don't need to access these performance statistics.
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/papr_scm: Limit the readability of 'perf_stats' sysfs attribute
  https://git.kernel.org/powerpc/c/0460534b532e5518c657c7d6492b9337d975eaa3

cheers


Re: [PATCH kernel] powerpc/dma: Fix dma_map_ops::get_required_mask

2020-09-10 Thread Michael Ellerman
On Tue, 8 Sep 2020 11:51:06 +1000, Alexey Kardashevskiy wrote:
> There are 2 problems with it:
> 1. "<" vs expected "<<"
> 2. the shift number is an IOMMU page number mask, not an address mask
> as the IOMMU page shift is missing.
> 
> This did not hit us before f1565c24b596 ("powerpc: use the generic
> dma_ops_bypass mode") because we had there additional code to handle
> bypass mask so this chunk (almost?) never executed. However there
> were reports that aacraid does not work with "iommu=nobypass".
> After f1565c24b596, aacraid (and probably others which call
> dma_get_required_mask() before setting the mask) was unable to
> enable 64bit DMA and fall back to using IOMMU which was known not to work,
> one of the problems is double free of an IOMMU page.
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/dma: Fix dma_map_ops::get_required_mask
  https://git.kernel.org/powerpc/c/437ef802e0adc9f162a95213a3488e8646e5fc03

cheers


Re: [PATCH v2] cpuidle-pseries: Fix CEDE latency conversion from tb to us

2020-09-10 Thread Michael Ellerman
On Thu, 3 Sep 2020 14:57:27 +0530, Gautham R. Shenoy wrote:
> commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> of the Extended CEDE states advertised by the platform. The values
> advertised by the platform are in timebase ticks. However the cpuidle
> framework requires the latency values in microseconds.
> 
> If the tb-ticks value advertised by the platform correspond to a value
> smaller than 1us, during the conversion from tb-ticks to microseconds,
> in the current code, the result becomes zero. This is incorrect as it
> puts a CEDE state on par with the snooze state.
> 
> [...]

Applied to powerpc/fixes.

[1/1] cpuidle: pseries: Fix CEDE latency conversion from tb to us
  https://git.kernel.org/powerpc/c/1d3ee7df009a46440c58508b8819213c09503acd

cheers


Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay

2020-09-10 Thread Michael Ellerman
Michael Ellerman  writes:
> On Tue, 30 Jun 2020 11:29:35 +0930, Joel Stanley wrote:
>> It's not done anything for a long time. Save the percpu variable, and
>> emit a warning to remind users to not expect it to do anything.
>> 
>> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
>> Cc: sta...@vger.kernel.org # v3.14
>> Signed-off-by: Joel Stanley 
>> --
>> v2:
>>  Use pr_warn instead of WARN
>>  Reword and print proccess name with pid in message
>>  Leave CPU_FTR_SMT test in
>>  Add Fixes line
>> 
>> [...]
>
> Applied to powerpc/next.
>
> [1/1] powerpc: Warn about use of smt_snooze_delay
>   
> https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217

I applied v3 actually.

cheers


Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-10 Thread Michael Ellerman
Michael Ellerman  writes:
> On Tue, 28 Jul 2020 12:37:41 -0500, Nathan Lynch wrote:
>> The drmem lmb list can have hundreds of thousands of entries, and
>> unfortunately lookups take the form of linear searches. As long as
>> this is the case, traversals have the potential to monopolize the CPU
>> and provoke lockup reports, workqueue stalls, and the like unless
>> they explicitly yield.
>> 
>> Rather than placing cond_resched() calls within various
>> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
>> expression of the loop macro itself so users can't omit it.
>
> Applied to powerpc/next.
>
> [1/1] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
>   
> https://git.kernel.org/powerpc/c/9d6792ffe140240ae54c881cc4183f9acc24b4df

Some script gremlins here, I actually applied v3 (only once).

cheers


Re: [PATCH v3] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, workqueue stalls, and the like unless
> they explicitly yield.
> 
> Rather than placing cond_resched() calls within various
> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
> expression of the loop macro itself so users can't omit it.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
  https://git.kernel.org/powerpc/c/9d6792ffe140240ae54c881cc4183f9acc24b4df

cheers


Re: [PATCH 0/5] powerpc: Remove five unused variables

2020-09-09 Thread Michael Ellerman
On Tue, 19 Nov 2019 14:14:29 +0800, zhengbin wrote:
> zhengbin (5):
>   powerpc/fadump: Remove set but not used variable 'elf'
>   powerpc/perf: Remove set but not used variable 'target'
>   powerpc/powernv: Remove set but not used variable 'total_vfs'
>   powerpc/powernv: Remove set but not used variable 'pdn'
>   powerpc/powernv: Remove set but not used variable 'parent'
> 
> [...]

Patches 1, 2 & 5 applied to powerpc/next.

[1/5] powerpc/fadump: Remove set but not used variable 'elf'
  https://git.kernel.org/powerpc/c/738e6cad0ace88edec8f4ffa082749ad5df26409
[2/5] powerpc/perf: Remove set but not used variable 'target'
  https://git.kernel.org/powerpc/c/ef23cf9a89a7aec19a29d548d1e219d436b23b6e
[5/5] powerpc/powernv: Remove set but not used variable 'parent'
  https://git.kernel.org/powerpc/c/18102e4bcc47f5b5ac70e2e4461d022c1ee6df24

cheers


Re: [PATCH v2 0/4] ocxl: Cleanup AFU interrupt allocation

2020-09-09 Thread Michael Ellerman
On Fri, 3 Apr 2020 17:38:34 +0200, Frederic Barrat wrote:
> Short series to cleanup AFU interrupt allocation for opencapi.
> Current code was using its own allocation service, calling opal
> directly to get the trigger page. This is not needed and we can use
> xive to achieve the same thing. The only caveat is that the trigger
> page address is only valid after the interrupt has been mapped, but
> that is not a problem with the way the code is using it.
> No functional change.
> 
> [...]

Applied to powerpc/next.

[1/4] scsi: cxlflash: Access interrupt trigger page from xive directly
  https://git.kernel.org/powerpc/c/1e89da5ef9c28c673e86048c89ef9495618d987d
[2/4] ocxl: Access interrupt trigger page from xive directly
  https://git.kernel.org/powerpc/c/ad857d47df6a1adc9798558701dd5426643b859f
[3/4] ocxl: Don't return trigger page when allocating an interrupt
  https://git.kernel.org/powerpc/c/dde6f18a8779dcd88d9fd5d6336032fee7e07fcd
[4/4] ocxl: Remove custom service to allocate interrupts
  https://git.kernel.org/powerpc/c/374f6178f3483dcad151fc14b2fad92ed6652f07

cheers


Re: [PATCH] powerpc: hwrng; fix missing of_node_put()

2020-09-09 Thread Michael Ellerman
On Mon, 2 Jul 2018 11:08:16 +0200, Nicholas Mc Guire wrote:
>  The call to of_find_compatible_node() returns a node pointer with refcount
> incremented thus it must be explicitly decremented here before returning.

Applied to powerpc/next.

[1/1] powerpc/pseries: Fix missing of_node_put() in rng_init()
  https://git.kernel.org/powerpc/c/67c3e59443f5fc77be39e2ce0db75fbfa78c7965

cheers


Re: [PATCH] powerpc: icp-hv: fix missing of_node_put in success path

2020-09-09 Thread Michael Ellerman
On Wed, 4 Jul 2018 10:03:27 +0200, Nicholas Mc Guire wrote:
>  Both of_find_compatible_node() and of_find_node_by_type() will
> return a refcounted node on success - thus for the success path
> the node must be explicitly released with a of_node_put().

Applied to powerpc/next.

[1/1] powerpc/icp-hv: Fix missing of_node_put() in success path
  https://git.kernel.org/powerpc/c/d3e669f31ec35856f5e85df9224ede5bdbf1bc7b

cheers


Re: [PATCH 1/6] powerpc/powernv/smp: Fix spurious DBG() warning

2020-09-09 Thread Michael Ellerman
On Tue, 4 Aug 2020 10:54:05 +1000, Oliver O'Halloran wrote:
> When building with W=1 we get the following warning:
> 
>  arch/powerpc/platforms/powernv/smp.c: In function 
> ‘pnv_smp_cpu_kill_self’:
>  arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
>   empty body in an ‘if’ statement [-Werror=empty-body]
>276 |  cpu, srr1);
>|^
>  cc1: all warnings being treated as errors
> 
> [...]

Applied to powerpc/next.

[1/6] powerpc/powernv/smp: Fix spurious DBG() warning
  https://git.kernel.org/powerpc/c/f6bac19cf65c5be21d14a0c9684c8f560f2096dd
[2/6] powerpc/powernv: Include asm/powernv.h from the local powernv.h
  https://git.kernel.org/powerpc/c/8471c1dd93de9a2278d41c527b76291e4ace8f1c
[3/6] powerpc/powernv: Staticify functions without prototypes
  https://git.kernel.org/powerpc/c/3b70464aa78917e88c1d4bfc2100c344c0eda8e0
[4/6] powerpc/powernv: Fix spurious kerneldoc warnings in opal-prd.c
  https://git.kernel.org/powerpc/c/fb248c3121af713f31736af359608491544cfc23
[5/6] powerpc/powernv: Remove set but not used variable 'parent'
  https://git.kernel.org/powerpc/c/18102e4bcc47f5b5ac70e2e4461d022c1ee6df24
[6/6] powerpc/nx: Don't pack struct coprocessor_request_block
  https://git.kernel.org/powerpc/c/3ced132a055c4e5046d21732393ae6848ff309e0

cheers


Re: [PATCH] cxl: Rework error message for incompatible slots

2020-09-09 Thread Michael Ellerman
On Tue, 7 Apr 2020 13:56:01 +0200, Frederic Barrat wrote:
> Improve the error message shown if a capi adapter is plugged on a
> capi-incompatible slot directly under the PHB (no intermediate switch).

Applied to powerpc/next.

[1/1] cxl: Rework error message for incompatible slots
  https://git.kernel.org/powerpc/c/40ac790d99c6dd16b367d5c2339e446a5f1b0593

cheers


Re: [PATCH] powerpc/oprofile: fix spelling mistake "contex" -> "context"

2020-09-09 Thread Michael Ellerman
On Tue, 4 Aug 2020 18:43:16 +0100, Colin King wrote:
> There is a spelling mistake in a pr_debug message. Fix it.

Applied to powerpc/next.

[1/1] powerpc/oprofile: fix spelling mistake "contex" -> "context"
  https://git.kernel.org/powerpc/c/346427e668163e85cbbe14e4d9a2ddd49df1536c

cheers


Re: [v3 1/2] dts: ppc: t4240rdb: remove interrupts property

2020-09-09 Thread Michael Ellerman
On Wed, 27 May 2020 11:42:27 +0800, Biwen Li wrote:
> Since the interrupt pin for RTC DS1374 is not connected
> to the CPU on T4240RDB, remove the interrupt property
> from the device tree.
> 
> This also fix the following warning for hwclock.util-linux:
> $ hwclock.util-linux
> hwclock.util-linux: select() to /dev/rtc0
> to wait for clock tick timed out

Applied to powerpc/next.

[1/2] powerpc/dts/t4240rdb: remove interrupts property
  https://git.kernel.org/powerpc/c/8c7614d648037b0776e0b76cb62911be3b059ea4
[2/2] powerc/dtc/t1024rdb: remove interrupts property
  https://git.kernel.org/powerpc/c/843dc8ee23d1b353fa9cc24da3e52be0111d5931

cheers


Re: [PATCH 1/2] powerpc/vmemmap: Fix memory leak with vmemmap list allocation failures.

2020-09-09 Thread Michael Ellerman
On Fri, 31 Jul 2020 17:04:59 +0530, Aneesh Kumar K.V wrote:
> If we fail to allocate vmemmap list, we don't keep track of allocated
> vmemmap block buf. Hence on section deactivate we skip vmemmap block
> buf free. This results in memory leak.

Applied to powerpc/next.

[1/2] powerpc/vmemmap: Fix memory leak with vmemmap list allocation failures.
  https://git.kernel.org/powerpc/c/ccaea15296f9773abd43aaa17ee4b88848e4a505
[2/2] powerpc/vmemmap: Don't warn if we don't find a mapping vmemmap list entry
  https://git.kernel.org/powerpc/c/1c0a7ac0ec63ee626f669c9a4e278f6ae1dbfcf2

cheers


Re: [PATCH] arch/powerpc: use simple i2c probe function

2020-09-09 Thread Michael Ellerman
On Fri, 7 Aug 2020 17:27:13 +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
> 
> This avoids scanning the identifier tables during probes.

Applied to powerpc/next.

[1/1] powerpc: Use simple i2c probe function
  https://git.kernel.org/powerpc/c/6c9100ea39d209e1625ba0fe06134192d9c4752a

cheers


Re: [PATCH 0/2] powerpc: unrel_branch_check.sh: enable llvm-objdump

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 18:10:34 +1000, Stephen Rothwell wrote:
> These 2 patches enable this script to work properly when llvm-objtool
> is being used.
> 
> They depend on my previos series that make this script suck less.

Applied to powerpc/next.

[1/2] powerpc: unrel_branch_check.sh: use nm to find symbol value
  https://git.kernel.org/powerpc/c/b71dca9891b330d5c2d3ff5d41704aa6f64f8e32
[2/2] powerpc: unrel_branch_check.sh: enable the use of llvm-objdump v9, 10 or 
11
  https://git.kernel.org/powerpc/c/6b1992bcdee8b86a74362192d4d8906731918bcc

cheers


Re: [PATCH 0/7] powerpc: unrel_branch_check.sh: make it suck less

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 00:04:27 +1000, Stephen Rothwell wrote:
> Michael Ellerman: "who wants to make
> arch/powerpc/tools/unrel_branch_check.sh suck less"
> 
> This series is based off the current powerpc/next branch and keeps the
> same functionaity as the original except that it suppresses some error
> messages for early failures that still cause this script to succeed
> (as it always did).
> 
> [...]

Applied to powerpc/next.

[1/7] powerpc: unrel_branch_check.sh: fix shellcheck complaints
  https://git.kernel.org/powerpc/c/d9de6b0da85c9f51734f7648f6e860b89f94c801
[2/7] powerpc: unrel_branch_check.sh: simplify and combine some executions
  https://git.kernel.org/powerpc/c/20ff8ec182160df86571a8af5773ff1e52837d73
[3/7] powerpc: unrel_branch_check.sh: simplify objdump's asm output
  https://git.kernel.org/powerpc/c/4e71106c343c625c0bf72a65b244e35e7d2cd037
[4/7] powerpc: unrel_branch_check.sh: convert grep | sed | awk to just sed
  https://git.kernel.org/powerpc/c/3d97abbc9f6fe90973551f3e3eef47ffef863114
[5/7] powerpc: unrel_branch_check.sh: simplify and tidy up the final loop
  https://git.kernel.org/powerpc/c/b84eaab6ede6477484edc043456cf7d7cfc7f8b3
[6/7] powerpc: unrel_branch_check.sh: fix up the file header
  https://git.kernel.org/powerpc/c/3745ae63b405b09c86718f95d96c4b2d2827b087
[7/7] powerpc: unrel_branch_check.sh: exit silently for early errors
  https://git.kernel.org/powerpc/c/af13a2244d59c4d63a25abd8257cbaef9d9ffebc

cheers


Re: [PATCH] powerpc/tools: Remove 90 line limit in checkpatch script

2020-09-09 Thread Michael Ellerman
On Fri, 28 Aug 2020 12:05:42 +1000, Russell Currey wrote:
> As of commit bdc48fa11e46, scripts/checkpatch.pl now has a default line
> length warning of 100 characters.  The powerpc wrapper script was using
> a length of 90 instead of 80 in order to make checkpatch less
> restrictive, but now it's making it more restrictive instead.
> 
> I think it makes sense to just use the default value now.

Applied to powerpc/next.

[1/1] powerpc/tools: Remove 90 line limit in checkpatch script
  https://git.kernel.org/powerpc/c/0fb4871bcc8997acbb8edf14b301fc150101d6c0

cheers


Re: [PATCH] powerpc/64s: handle ISA v3.1 local copy-paste context switches

2020-09-09 Thread Michael Ellerman
On Tue, 25 Aug 2020 17:55:35 +1000, Nicholas Piggin wrote:
> The ISA v3.1 the copy-paste facility has a new memory move functionality
> which allows the copy buffer to be pasted to domestic memory (RAM) as
> opposed to foreign memory (accelerator).
> 
> This means the POWER9 trick of avoiding the cp_abort on context switch if
> the process had not mapped foreign memory does not work on POWER10. Do the
> cp_abort unconditionally there.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64s: handle ISA v3.1 local copy-paste context switches
  https://git.kernel.org/powerpc/c/dc462267d2d7aacffc3c1d99b02d7a7c59db7c66

cheers


Re: [PATCH] powerpc/pseries/eeh: Fix dumb linebreaks

2020-09-09 Thread Michael Ellerman
On Tue, 18 Aug 2020 14:45:57 +1000, Oliver O'Halloran wrote:
> These annoy me every time I see them. Why are they here? They're not even
> needed for 80cols compliance.

Applied to powerpc/next.

[1/1] powerpc/pseries/eeh: Fix dumb linebreaks
  https://git.kernel.org/powerpc/c/10bf59d923c2766ec8d6f0243481c865c7db9979

cheers


Re: [PATCH v3] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 10:11:31 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, workqueue stalls, and the like unless
> they explicitly yield.
> 
> Rather than placing cond_resched() calls within various
> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
> expression of the loop macro itself so users can't omit it.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
  https://git.kernel.org/powerpc/c/9d6792ffe140240ae54c881cc4183f9acc24b4df

cheers


Re: [PATCH] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal

2020-09-09 Thread Michael Ellerman
On Tue, 28 Jul 2020 12:37:41 -0500, Nathan Lynch wrote:
> The drmem lmb list can have hundreds of thousands of entries, and
> unfortunately lookups take the form of linear searches. As long as
> this is the case, traversals have the potential to monopolize the CPU
> and provoke lockup reports, workqueue stalls, and the like unless
> they explicitly yield.
> 
> Rather than placing cond_resched() calls within various
> for_each_drmem_lmb() loop blocks in the code, put it in the iteration
> expression of the loop macro itself so users can't omit it.

Applied to powerpc/next.

[1/1] powerpc/pseries: explicitly reschedule during drmem_lmb list traversal
  https://git.kernel.org/powerpc/c/9d6792ffe140240ae54c881cc4183f9acc24b4df

cheers


Re: [PATCH] powerpc/64: Remove unused generic_secondary_thread_init()

2020-09-09 Thread Michael Ellerman
On Wed, 19 Aug 2020 11:57:04 +1000, Michael Ellerman wrote:
> The last caller was removed in 2014 in commit fb5a515704d7 ("powerpc:
> Remove platforms/wsp and associated pieces").
> 
> As Jordan noticed even though there are no callers, the code above in
> fsl_secondary_thread_init() falls through into
> generic_secondary_thread_init(). So we can remove the _GLOBAL but not
> the body of the function.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc/64: Remove unused generic_secondary_thread_init()
  https://git.kernel.org/powerpc/c/529d2bd56ada4b8a4904909042792879868208cd

cheers


Re: [PATCH 1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac

2020-09-09 Thread Michael Ellerman
On Wed, 19 Aug 2020 11:57:19 +1000, Michael Ellerman wrote:
> These platforms don't show the MMU in /proc/cpuinfo, but they always
> use hash, so teach using_hash_mmu() that.

Applied to powerpc/next.

[1/9] selftests/powerpc: Make using_hash_mmu() work on Cell & PowerMac
  https://git.kernel.org/powerpc/c/34c103342be3f9397e656da7c5cc86e97b91f514
[2/9] selftests/powerpc: Give the bad_accesses test longer to run
  https://git.kernel.org/powerpc/c/17c98a541dc9bb1162877af41cddbdca043f9a59
[3/9] selftests/powerpc: Move set_dscr() into rfi_flush.c
  https://git.kernel.org/powerpc/c/d89002397cfb2b65267d6688fe671ee1cf7c5f0d
[4/9] selftests/powerpc: Include asm/cputable.h from utils.h
  https://git.kernel.org/powerpc/c/178282a054dced1a08a9683d41ac08cbace2b2fe
[5/9] selftests/powerpc: Don't run DSCR tests on old systems
  https://git.kernel.org/powerpc/c/4c3c3c502575556c4bc1b401235e641863b1bce6
[6/9] selftests/powerpc: Skip security tests on older CPUs
  https://git.kernel.org/powerpc/c/3a31518a242dcb262b008d3bb5d4b1cf50cf4026
[7/9] selftests/powerpc: Skip L3 bank test on older CPUs
  https://git.kernel.org/powerpc/c/4871a10b7b5f6b0632bff229884dad1cb1e8dc37
[8/9] selftests/powerpc: Don't touch VMX/VSX on older CPUs
  https://git.kernel.org/powerpc/c/09275d717d1b2d7d5ed91f2140bb34246514a1b4
[9/9] selftests/powerpc: Properly handle failure in switch_endian_test
  https://git.kernel.org/powerpc/c/003d6f5fd2cc3b529f3e6c529bc4bb0792930212

cheers


Re: [PATCH 1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline

2020-09-09 Thread Michael Ellerman
On Thu, 13 Aug 2020 11:34:43 +1000, Michael Ellerman wrote:
> Several of the TM tests fail spuriously if CPU 0 is offline, because
> they blindly try to affinitise to CPU 0.
> 
> Fix them by picking any online CPU and using that instead.

Applied to powerpc/next.

[1/3] selftests/powerpc: Fix TM tests when CPU 0 is offline
  https://git.kernel.org/powerpc/c/c0176429b7b07893a5c1fd38baff055c919ba9e3
[2/3] selftests/powerpc: Don't use setaffinity in tm-tmspr
  https://git.kernel.org/powerpc/c/769628710c33b18ede837bb488e1d24084b35592
[3/3] selftests/powerpc: Run tm-tmspr test for longer
  https://git.kernel.org/powerpc/c/b5a646a681f5d67ea5190a71d6e84a91efe63b7a

cheers


Re: [PATCH v5 0/4] Allow bigger 64bit window by removing default DMA window

2020-09-09 Thread Michael Ellerman
On Wed, 5 Aug 2020 00:04:51 -0300, Leonardo Bras wrote:
> There are some devices in which a hypervisor may only allow 1 DMA window
> to exist at a time, and in those cases, a DDW is never created to them,
> since the default DMA window keeps using this resource.
> 
> LoPAR recommends this procedure:
> 1. Remove the default DMA window,
> 2. Query for which configs the DDW can be created,
> 3. Create a DDW.
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc/pseries/iommu: Create defines for operations in ibm, 
ddw-applicable
  https://git.kernel.org/powerpc/c/cac3e629086f1b2e31c87a6c9b0130d29843ae86
[2/4] powerpc/pseries/iommu: Update call to ibm, query-pe-dma-windows
  https://git.kernel.org/powerpc/c/80f0251231131d164eddab78d2b6c1b8e37d0093
[3/4] powerpc/pseries/iommu: Move window-removing part of remove_ddw into 
remove_dma_window
  https://git.kernel.org/powerpc/c/74d0b3994e147a2b503170b5e02f1d07dc086586
[4/4] powerpc/pseries/iommu: Allow bigger 64bit window by removing default DMA 
window
  https://git.kernel.org/powerpc/c/8c0d51592f6f0123953633d1ecf21e843fce0bfd

cheers


Re: [PATCH v3] powerpc: Warn about use of smt_snooze_delay

2020-09-09 Thread Michael Ellerman
On Wed, 2 Sep 2020 09:30:11 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
> 
> This uses pr_warn_once instead of pr_warn_ratelimit as testing
> 'ppc64_cpu --smt=off' on a 24 core / 4 SMT system showed the warning to
> be noisy, as the online/offline loop is slow.
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Warn about use of smt_snooze_delay
  https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217

cheers


Re: [PATCH v2] powerpc: Warn about use of smt_snooze_delay

2020-09-09 Thread Michael Ellerman
On Tue, 30 Jun 2020 11:29:35 +0930, Joel Stanley wrote:
> It's not done anything for a long time. Save the percpu variable, and
> emit a warning to remind users to not expect it to do anything.
> 
> Fixes: 3fa8cad82b94 ("powerpc/pseries/cpuidle: smt-snooze-delay cleanup.")
> Cc: sta...@vger.kernel.org # v3.14
> Signed-off-by: Joel Stanley 
> --
> v2:
>  Use pr_warn instead of WARN
>  Reword and print proccess name with pid in message
>  Leave CPU_FTR_SMT test in
>  Add Fixes line
> 
> [...]

Applied to powerpc/next.

[1/1] powerpc: Warn about use of smt_snooze_delay
  https://git.kernel.org/powerpc/c/a02f6d42357acf6e5de6ffc728e6e77faf3ad217

cheers


Re: [PATCH] powerpc/powernv: Print helpful message when cores guarded

2020-09-09 Thread Michael Ellerman
On Thu, 1 Aug 2019 14:46:30 +0930, Joel Stanley wrote:
> Often the firmware will guard out cores after a crash. This often
> undesirable, and is not immediately noticeable.
> 
> This adds an informative message when a CPU device tree nodes are marked
> bad in the device tree.

Applied to powerpc/next.

[1/1] powerpc/powernv: Print helpful message when cores guarded
  https://git.kernel.org/powerpc/c/8f55984f530d7275531e17f36ea29229c2c410dd

cheers


Re: [PATCH v2] powerpc: Update documentation of ISA versions for Power10

2020-09-09 Thread Michael Ellerman
On Thu, 27 Aug 2020 14:05:56 +1000, Jordan Niethe wrote:
> Update the CPU to ISA Version Mapping document to include Power10 and
> ISA v3.1.

Applied to powerpc/next.

[1/1] powerpc: Update documentation of ISA versions for Power10
  https://git.kernel.org/powerpc/c/51a1588154cb1ddc4fe8fa786324dca398f1a458

cheers


Re: [PATCH] selftests/powerpc: Fix prefixes in alignment_handler signal handler

2020-09-09 Thread Michael Ellerman
On Mon, 24 Aug 2020 23:12:31 +1000, Jordan Niethe wrote:
> The signal handler in the alignment handler self test has the ability to
> jump over the instruction that triggered the signal. It does this by
> incrementing the PT_NIP in the user context by 4. If it were a prefixed
> instruction this will mean that the suffix is then executed which is
> incorrect. Instead check if the major opcode indicates a prefixed
> instruction (e.g. it is 1) and if so increment PT_NIP by 8.
> 
> [...]

Applied to powerpc/next.

[1/1] selftests/powerpc: Fix prefixes in alignment_handler signal handler
  https://git.kernel.org/powerpc/c/db96221a683342fd4775fd820a4d5376cd2f2ed0

cheers


Re: [PATCH] powerpc/boot: Update Makefile comment for 64bit wrapper

2020-09-09 Thread Michael Ellerman
On Tue, 25 Aug 2020 13:51:47 +1000, Jordan Niethe wrote:
> As of commit 147c05168fc8 ("powerpc/boot: Add support for 64bit little
> endian wrapper") the comment in the Makefile is misleading. The wrapper
> packaging 64bit kernel may built as a 32 or 64 bit elf. Update the
> comment to reflect this.

Applied to powerpc/next.

[1/1] powerpc/boot: Update Makefile comment for 64bit wrapper
  https://git.kernel.org/powerpc/c/364b236a0b6e86439b9025d961da8602db23d5bf

cheers


Re: [PATCH v2] powerpc: Remove flush_instruction_cache() on 8xx

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 05:49:29 + (UTC), Christophe Leroy wrote:
> flush_instruction_cache() is never used on 8xx, remove it.

Applied to powerpc/next.

[1/1] powerpc: Remove flush_instruction_cache() on 8xx
  https://git.kernel.org/powerpc/c/76d46a1e2fe2c35f24c07b7cc8a41afbf98b349e

cheers


Re: [PATCH][V2] macintosh: windfarm: remove detatch debug containing spelling mistakes

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 11:29:01 +0100, Colin King wrote:
> There are spelling mistakes in two debug messages. As recommended
> by Wolfram Sang, these can be removed as there is plenty of debug
> in the driver core.

Applied to powerpc/next.

[1/1] macintosh: windfarm: remove detatch debug containing spelling mistakes
  https://git.kernel.org/powerpc/c/7db0a07273e8f581d0b3e8a102d3d9dd99f43528

cheers


Re: [PATCH v3 1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()

2020-09-09 Thread Michael Ellerman
On Wed, 12 Aug 2020 12:25:16 + (UTC), Christophe Leroy wrote:
> At the time being, __put_user()/__get_user() and friends only use
> D-form addressing, with 0 offset. Ex:
> 
>   lwz reg1, 0(reg2)
> 
> Give the compiler the opportunity to use other adressing modes
> whenever possible, to get more optimised code.
> 
> [...]

Applied to powerpc/next.

[1/2] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
  https://git.kernel.org/powerpc/c/c20beffeec3cb6f6f52d9aef27f91a3f453a91f4
[2/2] powerpc/uaccess: Add pre-update addressing to __get_user_asm() and 
__put_user_asm()
  https://git.kernel.org/powerpc/c/2f279eeb68b8eda43a95255db701b4faaeedbe0f

cheers


Re: [PATCH v2] powerpc: Drop _nmask_and_or_msr()

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 06:54:49 + (UTC), Christophe Leroy wrote:
> _nmask_and_or_msr() is only used at two places to set MSR_IP.
> 
> The SYNC is unnecessary as the users are not PowerPC 601.
> 
> Can be easily writen in C.
> 
> Do it, and drop _nmask_and_or_msr()

Applied to powerpc/next.

[1/1] powerpc: Drop _nmask_and_or_msr()
  https://git.kernel.org/powerpc/c/e53281bc21f061f96c9004f534bc3e807d70cb73

cheers


Re: [PATCH v2 1/4] powerpc: Remove flush_instruction_cache for book3s/32

2020-09-09 Thread Michael Ellerman
On Fri, 14 Aug 2020 05:56:24 + (UTC), Christophe Leroy wrote:
> The only callers of flush_instruction_cache() are:
> 
> arch/powerpc/kernel/swsusp_booke.S:   bl flush_instruction_cache
> arch/powerpc/mm/nohash/40x.c: flush_instruction_cache();
> arch/powerpc/mm/nohash/44x.c: flush_instruction_cache();
> arch/powerpc/mm/nohash/fsl_booke.c:   flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c:   
> flush_instruction_cache();
> arch/powerpc/platforms/44x/machine_check.c:   
> flush_instruction_cache();
> 
> [...]

Applied to powerpc/next.

[1/4] powerpc: Remove flush_instruction_cache for book3s/32
  https://git.kernel.org/powerpc/c/e426ab39f41045a4c163031272b2f48d944b69c0
[2/4] powerpc: Move flush_instruction_cache() prototype in asm/cacheflush.h
  https://git.kernel.org/powerpc/c/f663f3312051402d32952c44d156a20c0b854753
[3/4] powerpc: Rewrite 4xx flush_cache_instruction() in C
  https://git.kernel.org/powerpc/c/de39b19452e784de5f90ae899851ab29a29bb42c
[4/4] powerpc: Rewrite FSL_BOOKE flush_cache_instruction() in C
  https://git.kernel.org/powerpc/c/704dfe931df951895dea98bd1d9cacbb601b6451

cheers


Re: [PATCH v1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER

2020-09-09 Thread Michael Ellerman
On Mon, 17 Aug 2020 05:46:39 + (UTC), Christophe Leroy wrote:
> ftrace_graph_ret_addr() is always defined and returns 'ip' when
> CONFIG_FUNCTION GRAPH_TRACER is not set.
> 
> So the #ifdef is not needed, remove it.

Applied to powerpc/next.

[1/1] powerpc/process: Remove unnecessary #ifdef CONFIG_FUNCTION_GRAPH_TRACER
  https://git.kernel.org/powerpc/c/353bce211e00d183344f464ba1ee0e1ffb0e2a6c

cheers


Re: [PATCH] powerpc/irq: Drop forward declaration of struct irqaction

2020-09-09 Thread Michael Ellerman
On Thu, 6 Aug 2020 12:19:46 + (UTC), Christophe Leroy wrote:
> Since the commit identified below, the forward declaration of
> struct irqaction is useless. Drop it.

Applied to powerpc/next.

[1/1] powerpc/irq: Drop forward declaration of struct irqaction
  https://git.kernel.org/powerpc/c/b134cfc3e3276ccd5d29e39de5c848a45b08e410

cheers


  1   2   3   4   5   6   7   8   9   10   >