[PATCH] tools headers UAPI: Sync linux/types.h with the kernel sources
Unlike the other headers in tools/include/uapi/linux, types.h has never been synced from the exported headers, instead it's been hand written over time. This means it doesn't match the exported headers which can cause build errors on some architectures. For example on powerpc, tools/bpf doesn't build: $ make O=/build -C tools/bpf/ make: Entering directory '/linux/tools/bpf' Auto-detecting system features: ...libbfd: [ on ] ...disassembler-four-args: [ on ] CC /build/bpf_jit_disasm.o LINK /build/bpf_jit_disasm CC /build/bpf_dbg.o In file included from /usr/include/powerpc64le-linux-gnu/asm/sigcontext.h:14, from /usr/include/powerpc64le-linux-gnu/bits/sigcontext.h:30, from /usr/include/signal.h:288, from /linux/tools/bpf/bpf_dbg.c:51: /usr/include/powerpc64le-linux-gnu/asm/elf.h:160:9: error: unknown type name '__vector128' 160 | typedef __vector128 elf_vrreg_t; | ^~~ make: *** [Makefile:67: /build/bpf_dbg.o] Error 1 This is because tools/include/uapi/linux/types.h doesn't include asm/types.h, where __vector128 is defined in the powerpc headers. We can fix it by syncing the tools header with the exported kernel header, as is done for the other headers in tools/include/uapi/linux. Reported-by: Vitaly Chikunov Signed-off-by: Michael Ellerman --- Earlier discussion: https://lore.kernel.org/netdev/20201024203040.4cjxnxrdy6qx5...@altlinux.org/ Build tested on powerpc and x86. --- tools/include/uapi/linux/types.h | 41 ++-- 1 file changed, 34 insertions(+), 7 deletions(-) diff --git a/tools/include/uapi/linux/types.h b/tools/include/uapi/linux/types.h index 91fa51a9c31d..999cb0fa88eb 100644 --- a/tools/include/uapi/linux/types.h +++ b/tools/include/uapi/linux/types.h @@ -1,11 +1,26 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef _UAPI_LINUX_TYPES_H -#define _UAPI_LINUX_TYPES_H +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _LINUX_TYPES_H +#define _LINUX_TYPES_H -#include +#include + +#ifndef __ASSEMBLY__ + +#include + + +/* + * Below are truly Linux-specific types that should never collide with + * any application/library that wants linux/types.h. + */ + +#ifdef __CHECKER__ +#define __bitwise__ __attribute__((bitwise)) +#else +#define __bitwise__ +#endif +#define __bitwise __bitwise__ -/* copied from linux:include/uapi/linux/types.h */ -#define __bitwise typedef __u16 __bitwise __le16; typedef __u16 __bitwise __be16; typedef __u32 __bitwise __le32; @@ -16,8 +31,20 @@ typedef __u64 __bitwise __be64; typedef __u16 __bitwise __sum16; typedef __u32 __bitwise __wsum; +/* + * aligned_u64 should be used in defining kernel<->userspace ABIs to avoid + * common 32/64-bit compat problems. + * 64-bit values align to 4-byte boundaries on x86_32 (and possibly other + * architectures) and to 8-byte boundaries on 64-bit architectures. The new + * aligned_64 type enforces 8-byte alignment so that structs containing + * aligned_64 values have the same alignment on 32-bit and 64-bit architectures. + * No conversions are necessary between 32-bit user-space and a 64-bit kernel. + */ #define __aligned_u64 __u64 __attribute__((aligned(8))) #define __aligned_be64 __be64 __attribute__((aligned(8))) #define __aligned_le64 __le64 __attribute__((aligned(8))) -#endif /* _UAPI_LINUX_TYPES_H */ +typedef unsigned __bitwise __poll_t; + +#endif /* __ASSEMBLY__ */ +#endif /* _LINUX_TYPES_H */ -- 2.25.1
[PATCH] genirq: Fix export of irq_to_desc() for powerpc KVM
Commit 64a1b95bb9fe ("genirq: Restrict export of irq_to_desc()")
removed the export of irq_to_desc() unless powerpc KVM is being built,
because there is still a use of irq_to_desc() in modular code there.
However it used:
#ifdef CONFIG_KVM_BOOK3S_64_HV
Which doesn't work when that symbol is =m, leading to a build failure:
ERROR: modpost: "irq_to_desc" [arch/powerpc/kvm/kvm-hv.ko] undefined!
Fix it by checking for the definedness of the correct symbol which is
CONFIG_KVM_BOOK3S_64_HV_MODULE.
Fixes: 64a1b95bb9fe ("genirq: Restrict export of irq_to_desc()")
Signed-off-by: Michael Ellerman
---
kernel/irq/irqdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 3d0bc38a0bcf..cc1a09406c6e 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -352,7 +352,7 @@ struct irq_desc *irq_to_desc(unsigned int irq)
{
return radix_tree_lookup(&irq_desc_tree, irq);
}
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_64_HV_MODULE
EXPORT_SYMBOL_GPL(irq_to_desc);
#endif
--
2.25.1
[GIT PULL] Please pull powerpc/linux.git powerpc-5.11-2 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some powerpc fixes for 5.11: The following changes since commit 8a5be36b9303ae167468d4f5e1b3c090b9981396: Merge tag 'powerpc-5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2020-12-17 13:34:25 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.11-2 for you to fetch changes up to d5c243989fb0cb03c74d7340daca3b819f706ee7: powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too (2020-12-21 22:24:00 +1100) - -- powerpc fixes for 5.11 #2 Four commits fixing various things in the new C VDSO code. One fix for a 32-bit VMAP stack bug. Two minor build fixes. Thanks to: Cédric Le Goater, Christophe Leroy, Will Springer. - -- Christophe Leroy (2): powerpc/time: Force inlining of get_tb() powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too Cédric Le Goater (1): powerpc/smp: Add __init to init_big_cores() Michael Ellerman (4): powerpc/boot: Fix build of dts/fsl powerpc/vdso: Block R_PPC_REL24 relocations powerpc/vdso: Don't pass 64-bit ABI cflags to 32-bit VDSO powerpc/vdso: Fix DOTSYM for 32-bit LE VDSO arch/powerpc/boot/Makefile | 2 ++ arch/powerpc/include/asm/ppc_asm.h | 7 +- arch/powerpc/include/asm/vdso/timebase.h | 2 +- arch/powerpc/kernel/head_32.h| 25 +--- arch/powerpc/kernel/smp.c| 2 +- arch/powerpc/kernel/vdso32/Makefile | 4 ++-- arch/powerpc/kernel/vdso64/Makefile | 2 +- 7 files changed, 29 insertions(+), 15 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/j9DYACgkQUevqPMjh pYBjQQ/8CcfenT8pA9/vHqI/soyjASFrFtQLiHz1IrAJtzs1USnOrI9JhTYOsLlb HoUBITMzHJx9TkcT5l06f+BdscNRuCoxn3QLzfBZZkAFHK2Rfn51xJ7Un+THyZzc 3jqtuzrfBaoq3Ccut7Y0QrfuGW6eV+Q26/JThZJBee/K6jzBucPV7ZA/xA4qpLyY XxAnubSK/kMQixOOWeCqAgjcx8/CHe1rf7UhT2rWdLDoaUxq7UjIpbZlZ2r8YwiO e7FbrWKps0o3RW5953mYhYyHpIKanJlnB2Hl90g/MBRuwDqcoiTeKuAQV/7fNWOx eWRA2FfEFON+j4/3LEs6IN+OxSEoF/DkfBFnFogdbx4sv2uwrXwlWzDyRfWJJSNK PHKdUXE7sST4U9QgCZ0Mn5vz6BvCLWRFTowP4VR//we+xSyYca0s56XnKGZvEV/F dQ45aACT5EMjF1B/+AG725wf4ELKmxdJNXjLvrfuWuUsz5mt3Tl1Uh0pPmT3BD4B M1evyjp7+noSCjHYTooBiVqJwM2begiGBM4pD0UqLHt4cl6xvGhUE/LckJKmsPxn /WtXnXTg+/zBFO0NZ0s7UVcbO5sCpSVIRJ+cGL1AR/fWMSQBGxoH4JRJ4ov9rJGh /usuFCwBJKpRJxLFhgi5TrSnfYpoH+svHDU4deytU6wWmnenrzA= =V9FR -END PGP SIGNATURE-
Re: [PATCH] powerpc/32s: Fix RTAS machine check with VMAP stack
Christophe Leroy writes: > Le 22/12/2020 à 08:11, Christophe Leroy a écrit : >> When we have VMAP stack, exception prolog 1 sets r1, not r11. > > But exception prolog 1 uses r1 to setup r1 when machine check happens in > kernel. > So r1 must be restored when the branch is not taken. See subsequent patch I > just sent out. OK. This is still on the tip of fixes, so I'll rewind it to drop this commit, and then apply this and the fixup as one patch next week. cheers
Re: [PATCH] powerpc/32s: Fix RTAS machine check with VMAP stack
On Tue, 22 Dec 2020 07:11:18 + (UTC), Christophe Leroy wrote: > When we have VMAP stack, exception prolog 1 sets r1, not r11. Applied to powerpc/fixes. [1/1] powerpc/32s: Fix RTAS machine check with VMAP stack https://git.kernel.org/powerpc/c/9c7422b92cb27369653c371ad9c44a502e5eea8f cheers
Re: [PATCH] powerpc/time: Force inlining of get_tb()
On Sun, 20 Dec 2020 18:18:26 + (UTC), Christophe Leroy wrote: > Force inlining of get_tb() in order to avoid getting > following function in vdso32, leading to suboptimal > performance in clock_gettime() > > 0688 <.get_tb>: > 688: 7c 6d 42 a6 mftbu r3 > 68c: 7c 8c 42 a6 mftbr4 > 690: 7d 2d 42 a6 mftbu r9 > 694: 7c 03 48 40 cmplw r3,r9 > 698: 40 e2 ff f0 bne+688 <.get_tb> > 69c: 4e 80 00 20 blr Applied to powerpc/fixes. [1/1] powerpc/time: Force inlining of get_tb() https://git.kernel.org/powerpc/c/0faa22f09caadc11af2aa7570870ebd2ac5b8170 cheers
Re: [PATCH] powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too
On Mon, 21 Dec 2020 06:18:03 + (UTC), Christophe Leroy wrote: > We need r1 to be properly set before activating MMU, otherwise any new > exception taken while saving registers into the stack in syscall > prologs will use the user stack, which is wrong and will even lockup > or crash when KUAP is selected. > > Do that by switching the meaning of r11 and r1 until we have saved r1 > to the stack: copy r1 into r11 and setup the new stack pointer in r1. > To avoid complicating and impacting all generic and specific prolog > code (and more), copy back r1 into r11 once r11 is save onto > the stack. > > [...] Applied to powerpc/fixes. [1/1] powerpc/32: Fix vmap stack - Properly set r1 before activating MMU on syscall too https://git.kernel.org/powerpc/c/d5c243989fb0cb03c74d7340daca3b819f706ee7 cheers
Re: [PATCH v2 1/1] powerpc/kvm: Fix mask size for emulated msgsndp
On Tue, 8 Dec 2020 18:57:08 -0300, Leonardo Bras wrote: > According to ISAv3.1 and ISAv3.0b, the msgsndp is described to split RB in: > msgtype <- (RB) 32:36 > payload <- (RB) 37:63 > t <- (RB) 57:63 > > The current way of getting 'msgtype', and 't' is missing their MSB: > msgtype: ((arg >> 27) & 0xf) : Gets (RB) 33:36, missing bit 32 > t: (arg &= 0x3f) : Gets (RB) 58:63, missing bit 57 > > [...] Applied to powerpc/next. [1/1] KVM: PPC: Book3S HV: Fix mask size for emulated msgsndp https://git.kernel.org/powerpc/c/87fb4978ef8f7e3d6f51ea8e259638c4e96f2fc0 cheers
Re: [PATCH] KVM: PPC: Book3S: Assign boolean values to a bool variable
On Sat, 7 Nov 2020 14:26:22 +0800, xiakaixu1...@gmail.com wrote: > Fix the following coccinelle warnings: > > ./arch/powerpc/kvm/book3s_xics.c:476:3-15: WARNING: Assignment of 0/1 to bool > variable > ./arch/powerpc/kvm/book3s_xics.c:504:3-15: WARNING: Assignment of 0/1 to bool > variable Applied to powerpc/next. [1/1] KVM: PPC: Book3S: Assign boolean values to a bool variable https://git.kernel.org/powerpc/c/13751f8747519fe3bdc738fa6d802fbd94a85ac4 cheers
Re: [PATCH] powerpc/memhotplug: quieting some DLPAR operations
On Fri, 11 Dec 2020 15:59:54 +0100, Laurent Dufour wrote: > When attempting to remove by index a set of LMB a lot of messages are > displayed on the console, even when everything goes fine: > > pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 802d > Offlined Pages 4096 > pseries-hotplug-mem: Memory at 2d000 was hot-removed > > [...] Applied to powerpc/next. [1/1] powerpc/pseries/memhotplug: Quieten some DLPAR operations https://git.kernel.org/powerpc/c/20e9de85edae3a5866f29b6cce87c9ec66d62a1b cheers
Re: [PATCH] powerpc/mm: Fix hugetlb_free_pmd_range() and hugetlb_free_pud_range()
On Sat, 12 Dec 2020 13:41:25 + (UTC), Christophe Leroy wrote:
> Commit 7bfe54b5f165 ("powerpc/mm: Refactor the floor/ceiling check in
> hugetlb range freeing functions") inadvertely removed the mask
> applied to start parameter in those two functions, leading to the
> following crash on power9.
>
> [ 7703.114640][T58070] LTP: starting hugemmap05_1 (hugemmap05 -m)
> [ 7703.157792][ C99] [ cut here ]
> [ 7703.158279][ C99] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:387!
> [ 7703.158306][ C99] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 7703.158330][ C99] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=256 NUMA PowerNV
> [ 7703.158343][ C99] Modules linked in: vfio_pci vfio_virqfd
> vfio_iommu_spapr_tce vfio vfio_spapr_eeh loop kvm_hv kvm ip_tables x_tables
> sd_mod ahci libahci tg3 libata firmware_class libphy dm_mirror dm_region_hash
> dm_log dm_mod [last unloaded: dummy_del_mod]
> [ 7703.158435][ C99] CPU: 99 PID: 308 Comm: ksoftirqd/99 Tainted: G
> O 5.10.0-rc7-next-20201211 #1
> [ 7703.158464][ C99] NIP: c005dbec LR: c03352f4 CTR:
>
> [ 7703.158489][ C99] REGS: c0002bb6f830 TRAP: 0700 Tainted: G
> O (5.10.0-rc7-next-20201211)
> [ 7703.158528][ C99] MSR: 9282b033
> CR: 24002284 XER: 2004
> [ 7703.158570][ C99] GPR00: c03352f4 c0002bb6fad0
> c7f70b00 c0002000385b3ff0
> [ 7703.158570][ C99] GPR04: 0003
> c0002bb6f8b4 0001
> [ 7703.158570][ C99] GPR08: 0001 0009
> 0008 0002
> [ 7703.158570][ C99] GPR12: 24002488 c000201fff649c00
> c7f2a20c
> [ 7703.158570][ C99] GPR16: 0007
> c0194d10 c0194d10
> [ 7703.158570][ C99] GPR24: 0014 0015
> c000201cc6e72398 c7fac4b4
> [ 7703.158570][ C99] GPR28: c7f2bf80 c7fac2f8
> 0008 c00020003387
> [ 7703.158766][ C99] NIP [c005dbec] __tlb_remove_table+0x1dc/0x1e0
> pgtable_free at arch/powerpc/mm/book3s64/pgtable.c:387
> (inlined by) __tlb_remove_table at arch/powerpc/mm/book3s64/pgtable.c:405
> [ 7703.158805][ C99] LR [c03352f4] tlb_remove_table_rcu+0x54/0xa0
> [ 7703.158853][ C99] Call Trace:
> [ 7703.158872][ C99] [c0002bb6fad0] [c005db4c]
> __tlb_remove_table+0x13c/0x1e0 (unreliable)
> [ 7703.158890][ C99] [c0002bb6fb00] [c03352f4]
> tlb_remove_table_rcu+0x54/0xa0
> __tlb_remove_table_free at mm/mmu_gather.c:101
> (inlined by) tlb_remove_table_rcu at mm/mmu_gather.c:156
> [ 7703.158927][ C99] [c0002bb6fb30] [c0194d7c]
> rcu_core+0x35c/0xbb0
> rcu_do_batch at kernel/rcu/tree.c:2502
> (inlined by) rcu_core at kernel/rcu/tree.c:2737
> [ 7703.158966][ C99] [c0002bb6fbf0] [c095a3d0]
> __do_softirq+0x480/0x704
> [ 7703.159006][ C99] [c0002bb6fd10] [c00cc1f4]
> run_ksoftirqd+0x74/0xd0
> run_ksoftirqd at kernel/softirq.c:651
> (inlined by) run_ksoftirqd at kernel/softirq.c:642
> [ 7703.159046][ C99] [c0002bb6fd30] [c01040c8]
> smpboot_thread_fn+0x278/0x320
> [ 7703.159096][ C99] [c0002bb6fda0] [c00fc8a4]
> kthread+0x1c4/0x1d0
> [ 7703.159145][ C99] [c0002bb6fe10] [c000d9fc]
> ret_from_kernel_thread+0x5c/0x80
> [ 7703.159183][ C99] Instruction dump:
> [ 7703.159204][ C99] 6000 7c0802a6 3c82f8b4 7fe3fb78 38847470 f8010040
> 482b4fc5 6000
> [ 7703.159248][ C99] 0fe0 7c0802a6 fbe10028 f8010040 <0fe0>
> 3c4c07f1 38422f10 7c0802a6
> [ 7703.159293][ C99] ---[ end trace 1d92a5231ba6a0d5 ]---
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Fix hugetlb_free_pmd_range() and hugetlb_free_pud_range()
https://git.kernel.org/powerpc/c/2198d4934ee8b81341a84c9ec8bb25b4b0d02522
cheers
Re: [PATCH] powerpc: force inlining of csum_partial() to avoid multiple csum_partial() with GCC10
On Thu, 15 Oct 2020 10:52:20 + (UTC), Christophe Leroy wrote: > ppc-linux-objdump -d vmlinux | grep -e "" -e > "<__csum_partial>" > > With gcc9 I get: > > c0017ef8 <__csum_partial>: > c00182fc: 4b ff fb fd bl c0017ef8 <__csum_partial> > c0018478: 4b ff fa 80 b c0017ef8 <__csum_partial> > c03e8458: 4b c2 fa a0 b c0017ef8 <__csum_partial> > c03e8518: 4b c2 f9 e1 bl c0017ef8 <__csum_partial> > c03ef410: 4b c2 8a e9 bl c0017ef8 <__csum_partial> > c03f0b24: 4b c2 73 d5 bl c0017ef8 <__csum_partial> > c04279a4: 4b bf 05 55 bl c0017ef8 <__csum_partial> > c0429820: 4b be e6 d9 bl c0017ef8 <__csum_partial> > c0429944: 4b be e5 b5 bl c0017ef8 <__csum_partial> > c042b478: 4b be ca 81 bl c0017ef8 <__csum_partial> > c042b554: 4b be c9 a5 bl c0017ef8 <__csum_partial> > c045f15c: 4b bb 8d 9d bl c0017ef8 <__csum_partial> > c0492190: 4b b8 5d 69 bl c0017ef8 <__csum_partial> > c0492310: 4b b8 5b e9 bl c0017ef8 <__csum_partial> > c0495594: 4b b8 29 65 bl c0017ef8 <__csum_partial> > c049c420: 4b b7 ba d9 bl c0017ef8 <__csum_partial> > c049c870: 4b b7 b6 89 bl c0017ef8 <__csum_partial> > c049c930: 4b b7 b5 c9 bl c0017ef8 <__csum_partial> > c04a9ca0: 4b b6 e2 59 bl c0017ef8 <__csum_partial> > c04bdde4: 4b b5 a1 15 bl c0017ef8 <__csum_partial> > c04be480: 4b b5 9a 79 bl c0017ef8 <__csum_partial> > c04be710: 4b b5 97 e9 bl c0017ef8 <__csum_partial> > c04c969c: 4b b4 e8 5d bl c0017ef8 <__csum_partial> > c04ca2fc: 4b b4 db fd bl c0017ef8 <__csum_partial> > c04cf5bc: 4b b4 89 3d bl c0017ef8 <__csum_partial> > c04d0440: 4b b4 7a b9 bl c0017ef8 <__csum_partial> > > [...] Applied to powerpc/next. [1/1] powerpc: force inlining of csum_partial() to avoid multiple csum_partial() with GCC10 https://git.kernel.org/powerpc/c/328e7e487a464aad024fbde6663b7859df082b7b cheers
Re: [PATCH 01/23] kernel: irq: irqdescs: warn on spurious IRQ
Andy Shevchenko writes:
> On Fri, Dec 18, 2020 at 4:37 PM Enrico Weigelt, metux IT consult
> wrote:
>
>> + if (printk_ratelimit())
>> + pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
>> + irq, hwirq, nr_irqs);
>
> Perhaps you missed pr_warn_ratelimit() macro which is already in the
> kernel for a long time.
pr_warn_ratelimited() which calls printk_ratelimited().
And see the comment above printk_ratelimit():
/*
* Please don't use printk_ratelimit(), because it shares ratelimiting state
* with all other unrelated printk_ratelimit() callsites. Instead use
* printk_ratelimited() or plain old __ratelimit().
*/
cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.11-1 tag
Colin Ian King (1):
powerpc: fix spelling mistake in Kconfig "seleted" -> "selected"
Cédric Le Goater (12):
KVM: PPC: Book3S HV: XIVE: Show detailed configuration in debug output
powerpc/xive: Rename XIVE_IRQ_NO_EOI to show its a flag
powerpc/xive: Introduce XIVE_IPI_HW_IRQ
powerpc/xive: Add a name to the IRQ domain
powerpc/xive: Add a debug_show handler to the XIVE irq_domain
powerpc: Increase NR_IRQS range to support more KVM guests
powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_SHIFT_BUG
powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_MASK_FW
powerpc/xive: Remove P9 DD1 flag XIVE_IRQ_FLAG_EOI_FW
powerpc/xive: Simplify xive_do_source_eoi()
powerpc/xive: Improve error reporting of OPAL calls
KVM: PPC: Book3S HV: XIVE: Add a comment regarding VP numbering
Daniel Axtens (3):
powerpc/feature-fixups: use a semicolon rather than a comma
selftests/powerpc: update .gitignore
powerpc: add security.config, enforcing lockdown=integrity
David Hildenbrand (8):
powerpc/powernv/memtrace: Don't leak kernel memory to user space
powerpc/powernv/memtrace: Fix crashing the kernel when enabling
concurrently
powerpc/mm: factor out creating/removing linear mapping
powerpc/mm: protect linear mapping modifications by a mutex
powerpc/mm: print warning in arch_remove_linear_mapping()
powerpc/book3s64/hash: Drop WARN_ON in hash__remove_section_mapping()
powerpc/mm: remove linear mapping if __add_pages() fails in
arch_add_memory()
powernv/memtrace: don't abuse memory hot(un)plug infrastructure for
memory allocations
Frederic Barrat (1):
powerpc/pseries: Define PCI bus speed for Gen4 and Gen5
Ganesh Goudar (1):
lkdtm/powerpc: Add SLB multihit test
Gautham R. Shenoy (5):
powerpc/smp: Parse ibm,thread-groups with multiple properties
powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map
powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic
powerpc/smp: Add support detecting thread-groups sharing L2 cache
powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache
Harish (1):
selftests/powerpc: Fix uninitialized variable warning
Jordan Niethe (6):
powerpc/64: Set up a kernel stack for secondaries before cpu_restore()
powerpc/64s: Convert some cpu_setup() and cpu_restore() functions to C
powerpc/64: Fix an EMIT_BUG_ENTRY in head_64.S
powerpc: Allow relative pointers in bug table entries
powerpc/book3s64/kexec: Clear CIABR on kexec
powerpc/powernv/idle: Restore CIABR after idle for Power9
Kaixu Xia (4):
powerpc/powernv/sriov: fix unsigned int win compared to less than zero
powerpc/mm: Fix comparing pointer to 0 warning
KVM: PPC: Book3S: Assign boolean values to a bool variable
KVM: PPC: fix comparison to bool warning
Laurent Dufour (1):
powerpc/pseries/memhotplug: Quieten some DLPAR operations
Leonardo Bras (1):
KVM: PPC: Book3S HV: Fix mask size for emulated msgsndp
Madhavan Srinivasan (2):
powerpc/perf: Use regs->nip when SIAR is zero
powerpc/perf: Fix Threshold Event Counter Multiplier width for P10
Mathieu Desnoyers (1):
powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
Michael Ellerman (12):
powerpc/85xx: Fix declaration made after definition
powerpc/ps3: Drop unused DBG macro
Merge branch 'fixes' into next
powerpc: Make NUMA depend on SMP
powerpc: Make NUMA default y for powernv
powerpc: Update NUMA Kconfig description & help text
powerpc/time: Fix mftb()/get_tb() for use with the compat VDSO
powerpc/barrier: Use CONFIG_PPC64 for barrier selection
powerpc: Inline setup_kup()
powerpc/configs: Add ppc64le_allnoconfig target
powerpc: Add config fragment for disabling -Werror
powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
Nathan Lynch (28):
powerpc/rtas: prevent suspend-related sys_rtas use on LE
powerpc/rtas: complete ibm,suspend-me status codes
powerpc/rtas: rtas_ibm_suspend_me -> rtas_ibm_suspend_me_unsafe
powerpc/rtas: add rtas_ibm_suspend_me()
powerpc/rtas: add rtas_activate_firmware()
powerpc/hvcall: add token and codes for H_VASI_SIGNAL
powerpc/pseries/mobility: don't error on absence of ibm, update-nodes
powerpc/pseries/mobility: add missing break to default case
powerpc/pseries/mobility: error message improvements
powerpc/pseries/mobility: use rtas_activate_firmware() on resume
powerpc/pseries/mobility: extract VASI session polling logic
powerpc/pseries/mobility: use stop_machine for join/suspend
powerpc/pseries/mobility: signal suspend cancellation to platform
powerpc/pseries/mobility: retry partition suspend after error
powerpc/rtas: dispatch partition
Re: [PATCH 0/3] powerpc: convert to use ARCH_ATOMIC
On Wed, 11 Nov 2020 21:07:20 +1000, Nicholas Piggin wrote: > This conversion seems to require generic atomic64 changes, looks > like nothing else uses ARCH_ATOMIC and GENERIC_ATOMIC64 yet. > > Thanks, > Nick > > Nicholas Piggin (3): > asm-generic/atomic64: Add support for ARCH_ATOMIC > powerpc/64s/iommu: don't use atomic_ function on atomic64_t type > powerpc: rewrite atomics to use ARCH_ATOMIC > > [...] Patch 2 applied to powerpc/next. [2/3] powerpc/64s/iommu: Don't use atomic_ function on atomic64_t type https://git.kernel.org/powerpc/c/c33cd1ed60013ec2ae50f91fed260def5f1d9851 cheers
Re: [PATCH v4 1/6] powerpc/book3s64/kuap: Improve error reporting with KUAP
On Wed, 9 Dec 2020 05:29:20 + (UTC), Christophe Leroy wrote:
> This partially reverts commit eb232b162446 ("powerpc/book3s64/kuap: Improve
> error reporting with KUAP") and update the fault handler to print
>
> [ 55.022514] Kernel attempted to access user page (7e6725b7) - exploit
> attempt? (uid: 0)
> [ 55.022528] BUG: Unable to handle kernel data access on read at
> 0x7e6725b7
> [ 55.022533] Faulting instruction address: 0xc0e8b9bc
> [ 55.022540] Oops: Kernel access of bad area, sig: 11 [#1]
>
>
> [...]
Patches 2-6 applied to powerpc/next.
[2/6] powerpc/mm: sanity_check_fault() should work for all, not only BOOK3S
https://git.kernel.org/powerpc/c/7ceb40027e19567a0a066e3b380cc034cdd9a124
[3/6] powerpc/fault: Unnest definition of page_fault_is_write() and
page_fault_is_bad()
https://git.kernel.org/powerpc/c/5250d026d241febfaf226d26cabe528fc478e225
[4/6] powerpc/mm: Move the WARN() out of bad_kuap_fault()
https://git.kernel.org/powerpc/c/3dc12dfe74300febc568c3b530c0f9bee01f2821
[5/6] powerpc/fault: Avoid heavy search_exception_tables() verification
https://git.kernel.org/powerpc/c/cbd7e6ca0210db05c315a27bb5db5a482f2772ce
[6/6] powerpc/fault: Perform exception fixup in do_page_fault()
https://git.kernel.org/powerpc/c/5f1888a077069988218805534f56b983b6d5710c
cheers
Re: [PATCH v1 01/20] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
On Thu, 22 Oct 2020 06:29:26 + (UTC), Christophe Leroy wrote: > On 8xx, we get the following features: > > [0.00] cpu_features = 0x0100 > [0.00] possible= 0x0120 > [0.00] always = 0x > > This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all > other configurations, the three lines should be equal. > > [...] Patches 1-19 applied to powerpc/next. [01/20] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32 https://git.kernel.org/powerpc/c/78665179e569c7e1fe102fb6c21d0f5b6951f084 [02/20] powerpc/mm: Add mask of always present MMU features https://git.kernel.org/powerpc/c/f9158d58a4e1d91f21741e4e8ebe67f770b84e12 [03/20] powerpc/mm: Remove flush_tlb_page_nohash() prototype. https://git.kernel.org/powerpc/c/a54d310856b9c1fe15ad67a2f8ee9edc02965a3a [04/20] powerpc/32s: Make bat_addrs[] static https://git.kernel.org/powerpc/c/03d5b19c7243d6e605d360972dd7b701e2b1ba72 [05/20] powerpc/32s: Use mmu_has_feature(MMU_FTR_HPTE_TABLE) instead of checking Hash var https://git.kernel.org/powerpc/c/4cc445b4ff456f3a3997c321d7a353360feea04f [06/20] powerpc/32s: Make Hash var static https://git.kernel.org/powerpc/c/4b74a35fc7e9b8efd9067b8a365bab0fefe889ff [07/20] powerpc/32s: Declare Hash related vars as __initdata https://git.kernel.org/powerpc/c/6e980b5c56a266de479fcd022a03e094574e9a03 [08/20] powerpc/32s: Move _tlbie() and _tlbia() prototypes to tlbflush.h https://git.kernel.org/powerpc/c/cfe32ad0b3dc74df34ab6fea38ccb1e53f904a10 [09/20] powerpc/32s: Inline _tlbie() on non SMP https://git.kernel.org/powerpc/c/b91280f3f36d64cc6f8022893af00935c99de197 [10/20] powerpc/32s: Move _tlbie() and _tlbia() in a new file https://git.kernel.org/powerpc/c/f265512582a047e09390b1b41384f365d7dc806f [11/20] powerpc/32s: Split and inline flush_tlb_mm() and flush_tlb_page() https://git.kernel.org/powerpc/c/fd1b4b7f51d0d75b73eeda41ef459ea7791aaab2 [12/20] powerpc/32s: Inline flush_tlb_range() and flush_tlb_kernel_range() https://git.kernel.org/powerpc/c/1e83396f29d75aae8a1d365f597996fec87ca4d0 [13/20] powerpc/32s: Split and inline flush_range() https://git.kernel.org/powerpc/c/91ec450f8d8c1e599a943c526ab1d2a4acf73c22 [14/20] powerpc/32s: Inline tlb_flush() https://git.kernel.org/powerpc/c/ef08d95546ccea540f6a592b89822bb085bf09c6 [15/20] powerpc/32s: Inline flush_hash_entry() https://git.kernel.org/powerpc/c/80007a17fc59bc2766f7d5cb2f79b4c65651504b [16/20] powerpc/32s: Move early_mmu_init() into mmu.c https://git.kernel.org/powerpc/c/068fdba10ea54b6ebc12c2b2d85020b2137316d1 [17/20] powerpc/32s: Remove CONFIG_PPC_BOOK3S_6xx https://git.kernel.org/powerpc/c/a6a50d8495d098b6459166c3707ab251d3dc9e06 [18/20] powerpc/32s: Regroup 603 based CPUs in cputable https://git.kernel.org/powerpc/c/ad510e37e4b48f7da462650946aeaa078b977277 [19/20] powerpc/32s: Make support for 603 and 604+ selectable https://git.kernel.org/powerpc/c/44e9754d63c7b419874e4c18c0b5e7a770e058c6 cheers
Re: [PATCH] powerpc/8xx: Fix early debug when SMC1 is relocated
On Fri, 4 Dec 2020 10:11:34 + (UTC), Christophe Leroy wrote: > When SMC1 is relocated and early debug is selected, the > board hangs is ppc_md.setup_arch(). This is because ones > the microcode has been loaded and SMC1 relocated, early > debug writes in the weed. > > To allow smooth continuation, the SMC1 parameter RAM set up > by the bootloader have to be copied into the new location. Applied to powerpc/next. [1/1] powerpc/8xx: Fix early debug when SMC1 is relocated https://git.kernel.org/powerpc/c/1e78f723d6a52966bfe3804209dbf404fdc9d3bb cheers
Re: [PATCH] powerpc/mm: Refactor the floor/ceiling check in hugetlb range freeing functions
On Fri, 6 Nov 2020 13:20:54 + (UTC), Christophe Leroy wrote:
> All hugetlb range freeing functions have a verification like the following,
> which only differs by the mask used, depending on the page table level.
>
> start &= MASK;
> if (start < floor)
> return;
> if (ceiling) {
> ceiling &= MASK;
> if (! ceiling)
> return;
> }
> if (end - 1 > ceiling - 1)
> return;
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/mm: Refactor the floor/ceiling check in hugetlb range freeing
functions
https://git.kernel.org/powerpc/c/7bfe54b5f16561bb703de6482f880614ada8dbf2
cheers
Re: [PATCH] powerpc/rtas: fix typo of ibm,open-errinjct in rtas filter
On Tue, 8 Dec 2020 13:54:34 -0600, Tyrel Datwyler wrote:
> Commit bd59380c5ba4 ("powerpc/rtas: Restrict RTAS requests from userspace")
> introduced the following error when invoking the errinjct userspace
> tool.
>
> [root@ltcalpine2-lp5 librtas]# errinjct open
> [327884.071171] sys_rtas: RTAS call blocked - exploit attempt?
> [327884.071186] sys_rtas: token=0x26, nargs=0 (called by errinjct)
> errinjct: Could not open RTAS error injection facility
> errinjct: librtas: open: Unexpected I/O error
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/rtas: Fix typo of ibm,open-errinjct in RTAS filter
https://git.kernel.org/powerpc/c/f10881a46f8914428110d110140a455c66bdf27b
cheers
Re: [PATCH v1 1/3] powerpc/32s: Remove unused counters incremented by create_hpte()
On Tue, 24 Nov 2020 19:51:55 + (UTC), Christophe Leroy wrote: > primary_pteg_full and htab_hash_searches are not used. > > Remove them. Applied to powerpc/next. [1/3] powerpc/32s: Remove unused counters incremented by create_hpte() https://git.kernel.org/powerpc/c/c5ccb4e78968fbe64f938a5a012fc8ec25cafabf [2/3] powerpc/32s: In add_hash_page(), calculate VSID later https://git.kernel.org/powerpc/c/fec6166b44ded68e68144144a02e498580118f1a [3/3] powerpc/32s: Cleanup around PTE_FLAGS_OFFSET in hash_low.S https://git.kernel.org/powerpc/c/da481c4fe0e485cdab5cf4d2761be8b8fb38d3d1 cheers
Re: [PATCH v3 0/5] Extend Parsing "ibm, thread-groups" for Shared-L2 information
On Thu, 10 Dec 2020 16:08:54 +0530, Gautham R. Shenoy wrote: > This is the v2 of the patchset to extend parsing of "ibm,thread-groups" > property > to discover the Shared-L2 cache information. > > The previous versions can be found here : > > v2 : > https://lore.kernel.org/linuxppc-dev/1607533700-5546-1-git-send-email-...@linux.vnet.ibm.com/T/#m043ea15d3832658527fca94765202b9cbefd330d > > [...] Applied to powerpc/next. [1/5] powerpc/smp: Parse ibm,thread-groups with multiple properties https://git.kernel.org/powerpc/c/790a1662d3a26fe9fa5f691386d8fde6bb8b0dc2 [2/5] powerpc/smp: Rename cpu_l1_cache_map as thread_group_l1_cache_map https://git.kernel.org/powerpc/c/1fdc1d6632ff3f6813a2f15b65586bde8fe0f0ba [3/5] powerpc/smp: Rename init_thread_group_l1_cache_map() to make it generic https://git.kernel.org/powerpc/c/fbd2b672e91d276b9fa5a729e4a823ba29fa2692 [4/5] powerpc/smp: Add support detecting thread-groups sharing L2 cache https://git.kernel.org/powerpc/c/9538abee18cca70ffd03cef56027388b0c5084cc [5/5] powerpc/cacheinfo: Print correct cache-sibling map/list for L2 cache https://git.kernel.org/powerpc/c/0be47634db0baa9e91c7e635e7e73355d6a5cf43 cheers
Re: [PATCH] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected"
On Mon, 7 Dec 2020 15:54:20 +, Colin King wrote: > There is a spelling mistake in the help text of the Kconfig. Fix it. Applied to powerpc/next. [1/1] powerpc: fix spelling mistake in Kconfig "seleted" -> "selected" https://git.kernel.org/powerpc/c/f8a4b277c3cf39ec8efe50114924a7743cc84800 cheers
Re: [PATCH] powerpc/process: Remove target specific __set_dabr()
On Fri, 4 Dec 2020 10:12:51 + (UTC), Christophe Leroy wrote: > __set_dabr() are simple functions that can be inline directly > inside set_dabr() and using IS_ENABLED() instead of #ifdef Applied to powerpc/next. [1/1] powerpc/process: Remove target specific __set_dabr() https://git.kernel.org/powerpc/c/ad3ed15cd04b96de7c38204ba7c698cbccd8fe88 cheers
Re: [PATCH v1 1/6] powerpc/8xx: DEBUG_PAGEALLOC doesn't require an ITLB miss exception handler
On Tue, 24 Nov 2020 15:24:54 + (UTC), Christophe Leroy wrote:
> Since commit e611939fc8ec ("powerpc/mm: Ensure change_page_attr()
> doesn't invalidate pinned TLBs"), pinned TLBs are not anymore
> invalidated by __kernel_map_pages() when CONFIG_DEBUG_PAGEALLOC is
> selected.
>
> Remove the dependency on CONFIG_DEBUG_PAGEALLOC.
Applied to powerpc/next.
[1/6] powerpc/8xx: DEBUG_PAGEALLOC doesn't require an ITLB miss exception
handler
https://git.kernel.org/powerpc/c/613df979da6c032cbe6fa273fb8ca21af022157e
[2/6] powerpc/8xx: Always pin kernel text TLB
https://git.kernel.org/powerpc/c/bccc58986a2f98e3af349c85c5f49aac7fb19ef2
[3/6] powerpc/8xx: Simplify INVALIDATE_ADJACENT_PAGES_CPU15
https://git.kernel.org/powerpc/c/576e02bbf1062b9118d5bbb96a40ed3b6b359f22
[4/6] powerpc/8xx: Use SPRN_SPRG_SCRATCH2 in ITLB miss exception
https://git.kernel.org/powerpc/c/a314ea5abf6dbaf35f14c9bd1d93105260fb9336
[5/6] powerpc/8xx: Use SPRN_SPRG_SCRATCH2 in DTLB miss exception
https://git.kernel.org/powerpc/c/89eecd938cab80f0da18abbd2ed997a521f83f01
[6/6] powerpc/ppc-opcode: Add PPC_RAW_MFSPR()
https://git.kernel.org/powerpc/c/70b588a068668dd7a92ed19cf0373ba92847957c
cheers
Re: [PATCH v2] powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK
On Tue, 8 Dec 2020 05:24:19 + (UTC), Christophe Leroy wrote: > low_sleep_handler() can't restore the context from standard > stack because the stack can hardly be accessed with MMU OFF. > > Store everything in a global storage area instead of storing > a pointer to the stack in that global storage area. > > To avoid a complete churn of the function, still use r1 as > the pointer to the storage area during restore. Applied to powerpc/next. [1/1] powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACK https://git.kernel.org/powerpc/c/db972a3787d12b1ce9ba7a31ec376d8a79e04c47 cheers
Re: [PATCH] powerpc/32s: Handle PROTFAULT in hash_page() also for CONFIG_PPC_KUAP
On Mon, 16 Nov 2020 16:09:31 + (UTC), Christophe Leroy wrote:
> On hash 32 bits, handling minor protection faults like unsetting
> dirty flag is heavy if done from the normal page_fault processing,
> because it implies hash table software lookup for flushing the entry
> and then a DSI is taken anyway to add the entry back.
>
> When KUAP was implemented, as explained in commit a68c31fc01ef
> ("powerpc/32s: Implement Kernel Userspace Access Protection"),
> protection faults has been diverted from hash_page() because
> hash_page() was not able to identify a KUAP fault.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/32s: Handle PROTFAULT in hash_page() also for CONFIG_PPC_KUAP
https://git.kernel.org/powerpc/c/1b03e71ff6f2bd10b45a0128ce76e0e42014a44c
cheers
Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
Nicholas Piggin writes: > Excerpts from Michael Ellerman's message of December 14, 2020 8:43 pm: >> Nicholas Piggin writes: >>> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm: Hi Nicholas, On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote: > > When offlining a CPU, powerpc/64s does not flush TLBs, rather it just > leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs > to manage its TLBs. > > However the exit_flush_lazy_tlbs() function expects that after > returning, all CPUs (except self) have flushed TLBs for that mm, in > which case TLBIEL can be used for this flush. This breaks for offline > CPUs because they don't get the IPI to flush their TLB. This can lead > to stale translations. > > Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs > before going offline. > > These offlined CPU bits stuck in the cpumask also prevents the cpumask > from being trimmed back to local mode, which means continual broadcast > IPIs or TLBIEs are needed for TLB flushing. This patch prevents that > situation too. > > Signed-off-by: Nicholas Piggin Thanks for your patch! > --- a/arch/powerpc/platforms/powermac/smp.c > +++ b/arch/powerpc/platforms/powermac/smp.c > @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void) > > mpic_cpu_set_priority(0xf); > > + cleanup_cpu_mmu_context(); > + I guess this change broke pmac32_defconfig+SMP in v5.10-rc7? arch/powerpc/platforms/powermac/smp.c: error: implicit declaration of function 'cleanup_cpu_mmu_context' [-Werror=implicit-function-declaration]: => 914:2 http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/ >>> >>> Hey, yeah it does thanks for catching it. This patch fixes it for me >>> >>> --- >>> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001 >>> From: Nicholas Piggin >>> Date: Mon, 14 Dec 2020 13:52:39 +1000 >>> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug >>> >>> 32s has no tlbiel_all() defined, so just disable the cleanup with a >>> comment. >> >> Or what about just: > > That works, I kind of wanted it in there explicit that we don't > clean up on 32s. I don't mind if you prefer this though. OK. I'll merge my version because I can do that without needing to merge master in order to get the broken commit into my tree. cheers
Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
Nicholas Piggin writes:
> Excerpts from Geert Uytterhoeven's message of December 10, 2020 7:06 pm:
>> Hi Nicholas,
>>
>> On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote:
>>>
>>> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
>>> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
>>> to manage its TLBs.
>>>
>>> However the exit_flush_lazy_tlbs() function expects that after
>>> returning, all CPUs (except self) have flushed TLBs for that mm, in
>>> which case TLBIEL can be used for this flush. This breaks for offline
>>> CPUs because they don't get the IPI to flush their TLB. This can lead
>>> to stale translations.
>>>
>>> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
>>> before going offline.
>>>
>>> These offlined CPU bits stuck in the cpumask also prevents the cpumask
>>> from being trimmed back to local mode, which means continual broadcast
>>> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
>>> situation too.
>>>
>>> Signed-off-by: Nicholas Piggin
>>
>> Thanks for your patch!
>>
>>> --- a/arch/powerpc/platforms/powermac/smp.c
>>> +++ b/arch/powerpc/platforms/powermac/smp.c
>>> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>>>
>>> mpic_cpu_set_priority(0xf);
>>>
>>> + cleanup_cpu_mmu_context();
>>> +
>>
>> I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
>>
>> arch/powerpc/platforms/powermac/smp.c: error: implicit
>> declaration of function 'cleanup_cpu_mmu_context'
>> [-Werror=implicit-function-declaration]: => 914:2
>>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
>
> Hey, yeah it does thanks for catching it. This patch fixes it for me
>
> ---
> From a9b5ec92ffac975e81c6d7db6ff2b1486b2723f7 Mon Sep 17 00:00:00 2001
> From: Nicholas Piggin
> Date: Mon, 14 Dec 2020 13:52:39 +1000
> Subject: [PATCH] powerpc/32s: Fix cleanup_cpu_mmu_context() compile bug
>
> 32s has no tlbiel_all() defined, so just disable the cleanup with a
> comment.
Or what about just:
diff --git a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
index 331187661236..685c589e723f 100644
--- a/arch/powerpc/include/asm/book3s/32/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/32/mmu-hash.h
@@ -94,6 +94,7 @@ typedef struct {
} mm_context_t;
void update_bats(void);
+static inline void cleanup_cpu_mmu_context(void) { };
/* patch sites */
extern s32 patch__hash_page_A0, patch__hash_page_A1, patch__hash_page_A2;
cheers
[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-6 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull one final powerpc fix for 5.10: The following changes since commit a1ee28117077c3bf24e5ab6324c835eaab629c45: powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE (2020-12-02 23:16:40 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.10-6 for you to fetch changes up to 5eedf9fe8db23313df104576845cec5f481b9b60: powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed() (2020-12-08 10:22:09 +1100) - -- powerpc fixes for 5.10 #6 One commit to implement copy_from_kernel_nofault_allowed(), otherwise copy_from_kernel_nofault() can trigger warnings when accessing bad addresses in some configurations. Thanks to: Christophe Leroy, Qian Cai. - -- Christophe Leroy (1): powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed() arch/powerpc/mm/Makefile | 2 +- arch/powerpc/mm/maccess.c | 9 + 2 files changed, 10 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/mm/maccess.c -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/SvGcACgkQUevqPMjh pYAecRAAhM0j56uNwH4P+Mu/PJ3PXjuoLjZGSA1HAOyBOamJsTvShW3R3w+bq+0A nKo1I7qkrCBmvTcKWc/XqRQom3I+bP/DbtHdXx0IEW8qooBRDIRRqEXCTXPOLxnh lESPuixsTofm+HBNpg/gY4/VXphVM3+0gLp05YQ0SdeWedPmiEzyYF7IKPrYiuzq 7yOqu2wqUQ9BewWIWllDy+z5bNDnww7f2VIudTfEmg0AACriXfRvRSFk5y78OBtk fMzO1q8FLdWXTpWOVJfDFRpwPMMSjRK8DJblROoPjidXg57Lj998DP4R0WZQmiqO OKIa2AGBm9ZZCYArFhTA4X4ObmKIZKIox1th4WOAljBeByVFX8m+FbW/ChET1CSE KGmr1djFuEMljlCPPMUSgAns/LAYr+BfL+XRyix3I8vgF9lWjR2G0K1z8LEmXSEF 0MzJ/loxYSdRd89pGSuinPS8VNBObcRFTfqVqGC0LpI2PeSpawjRUbl3AOTkISFs zwdWcJWwj/XME6yjcFhic3CuUvw74v/ZGHTpbsvov0eR2ki0D5zKq9GqGHVkMP+m 5Db7i5rLGsM5zy7M2OloPVL+C193cbrrMrk7ndv3HS6ojPErHukwQ1SoQJrrGAKN 8KDfJlQB8ofjpux3jS9JoDkXqQd7zjdX63Ob9nTyjIYn0V+TEyY= =g55c -END PGP SIGNATURE-
Re: [PATCH v2 00/25] powerpc: Switch signal 32 to using unsafe_put_user() and friends
On Tue, 18 Aug 2020 17:19:11 + (UTC), Christophe Leroy wrote: > This series leads to a reduction from 2.55s to 1.73s of > the system CPU time with the following microbench app > on an mpc832x with KUAP (approx 32%) > > This series replaces copies to users by unsafe_put_user() and friends > with user_write_access_begin() dance in signal32. > > [...] Applied to powerpc/next. [01/25] powerpc/signal: Move inline functions in signal.h https://git.kernel.org/powerpc/c/95593e930d7d067ca9bbee996c845248930a01f9 [02/25] powerpc/ptrace: Move declaration of ptrace_get_reg() and ptrace_set_reg() https://git.kernel.org/powerpc/c/67e364b3295f9dbf3b820d0edde86fb7c95efc98 [03/25] powerpc/ptrace: Consolidate reg index calculation https://git.kernel.org/powerpc/c/e009fa433542cd09d6279e361b767a1f44ffd29a [04/25] powerpc/ptrace: Create ptrace_get_fpr() and ptrace_put_fpr() https://git.kernel.org/powerpc/c/4d90eb97e292c7b14de8ba59fded35b340c73101 [05/25] powerpc/signal: Don't manage floating point regs when no FPU https://git.kernel.org/powerpc/c/b6254ced4da6cf28d49fbffe24ee4b3286dcb3f4 [06/25] powerpc/32s: Allow deselecting CONFIG_PPC_FPU on mpc832x https://git.kernel.org/powerpc/c/7d68c89169508064c460a1208f38ed0589d226fa [07/25] powerpc/signal: Remove BUG_ON() in handler_signal functions https://git.kernel.org/powerpc/c/3fcfb5d1bf731bdbd847c29df57a5372d8ea58d3 [08/25] powerpc/signal: Move access_ok() out of get_sigframe() https://git.kernel.org/powerpc/c/454b1abb588b3942655638a8bcf1ea4501260579 [09/25] powerpc/signal: Remove get_clean_sp() https://git.kernel.org/powerpc/c/0ecbc6ad18e324012234183e21805423f5e0cc79 [10/25] powerpc/signal: Call get_tm_stackpointer() from get_sigframe() https://git.kernel.org/powerpc/c/c180cb305c9bba094657259487d563c8fbfb648b [11/25] powerpc/signal: Refactor bad frame logging https://git.kernel.org/powerpc/c/7fe8f773ee248c726cec2addcdb94056049d6e34 [12/25] powerpc/signal32: Simplify logging in handle_rt_signal32() https://git.kernel.org/powerpc/c/debf122c777f361137a3114db7be8aecc65f6af2 [13/25] powerpc/signal32: Move handle_signal32() close to handle_rt_signal32() https://git.kernel.org/powerpc/c/3eea688be0ccba2221e047b7df6f9ae87361cdd6 [14/25] powerpc/signal32: Rename local pointers in handle_rt_signal32() https://git.kernel.org/powerpc/c/8e91cf8501f14d8b6727c71c98fd743e95e9b402 [15/25] powerpc/signal32: Misc changes to make handle_[rt_]_signal32() more similar https://git.kernel.org/powerpc/c/91b8ecd419cb46058e99b3a574184883c02b7729 [16/25] powerpc/signal32: Move signal trampoline setup to handle_[rt_]signal32 https://git.kernel.org/powerpc/c/8d33001dd650b88e915a1a13e2ca807350e374df [17/25] powerpc/signal32: Switch handle_signal32() to user_access_begin() logic https://git.kernel.org/powerpc/c/ad65f4909fd3736d84533784cd9ab76905536b34 [18/25] powerpc/signal32: Switch handle_rt_signal32() to user_access_begin() logic https://git.kernel.org/powerpc/c/9504db3e90b22dca19d8152ed5a82c68512dac0e [19/25] powerpc/signal32: Remove ifdefery in middle of if/else https://git.kernel.org/powerpc/c/f1cf4f93de2ff66313a091320d7683735816a0bc [20/25] signal: Add unsafe_put_compat_sigset() https://git.kernel.org/powerpc/c/14026b94ccfe626e512bc9fa01e0e72ee75c7a98 [21/25] powerpc/signal32: Add and use unsafe_put_sigset_t() https://git.kernel.org/powerpc/c/de781ebdf6b8a256742da4fd6b0e39bb22ed9fe3 [22/25] powerpc/signal32: Switch swap_context() to user_access_begin() logic https://git.kernel.org/powerpc/c/31147d7d6133ea17504b118114a191a8af85f3de [23/25] powerpc/signal: Create 'unsafe' versions of copy_[ck][fpr/vsx]_to_user() https://git.kernel.org/powerpc/c/b3484a1d4d1fb54ad7b615a13003d8bc11919c96 [24/25] powerpc/signal32: Isolate non-copy actions in save_user_regs() and save_tm_user_regs() https://git.kernel.org/powerpc/c/968c4fccd1bb8b440326dac5078ad87d17af4a47 [25/25] powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version https://git.kernel.org/powerpc/c/ef75e73182949a94bde169a774de1b62ae21fbbc cheers
Re: [PATCH] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx
On Mon, 12 Oct 2020 08:05:49 + (UTC), Christophe Leroy wrote: > Only mpc83xx will set MMU_FTR_NEED_DTLB_SW_LRU and its > definition is enclosed in #ifdef CONFIG_PPC_83xx. > > Make MMU_FTR_NEED_DTLB_SW_LRU possible only when > CONFIG_PPC_83xx is set. Applied to powerpc/next. [1/1] powerpc/mm: MMU_FTR_NEED_DTLB_SW_LRU is only possible with CONFIG_PPC_83xx https://git.kernel.org/powerpc/c/b68e3a3dff97bdc1cba79dc5f80cede8a2419cac cheers
Re: [PATCH] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x
On Sat, 10 Oct 2020 17:30:59 + (UTC), Christophe Leroy wrote: > MMU_FTR_TYPE_44x cannot be checked by cpu_has_feature() > > Use mmu_has_feature() instead Applied to powerpc/next. [1/1] powerpc/mm: Fix verification of MMU_FTR_TYPE_44x https://git.kernel.org/powerpc/c/17179aeb9d34cc81e1a4ae3f85e5b12b13a1f8d0 cheers
Re: [PATCH] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE
On Mon, 12 Oct 2020 08:02:13 + (UTC), Christophe Leroy wrote: > G2_LE has a 603 core, add CPU_FTR_NOEXECUTE. Applied to powerpc/next. [1/1] powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE https://git.kernel.org/powerpc/c/197493af414ee22427be3343637ac290a791925a cheers
Re: [PATCH] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
On Mon, 12 Oct 2020 08:02:30 + (UTC), Christophe Leroy wrote:
> Since commit 10b35d9978ac ("[PATCH] powerpc: merged asm/cputable.h"),
> CPU_FTR_COHERENT_ICACHE has always been defined.
>
> Remove the #ifndef CPU_FTR_COHERENT_ICACHE block.
Applied to powerpc/next.
[1/1] powerpc/mm: Remove useless #ifndef CPU_FTR_COHERENT_ICACHE in mem.c
https://git.kernel.org/powerpc/c/1a1be322178ca8097abeee244262ce0da5b519a9
cheers
Re: [PATCH] powerpc/time: Remove ifdef in get_vtb()
On Thu, 1 Oct 2020 10:59:20 + (UTC), Christophe Leroy wrote: > SPRN_VTB and CPU_FTR_ARCH_207S are always defined, > no need of an ifdef. Applied to powerpc/next. [1/1] powerpc/time: Remove ifdef in get_vtb() https://git.kernel.org/powerpc/c/c3cb5dbd85dbd9ae51fadf867782dc34806f04d8 cheers
Re: [PATCH 1/2] powerpc: Retire e200 core (mpc555x processor)
On Tue, 17 Nov 2020 05:07:58 + (UTC), Christophe Leroy wrote: > There is no defconfig selecting CONFIG_E200, and no platform. > > e200 is an earlier version of booke, a predecessor of e500, > with some particularities like an unified cache instead of both an > instruction cache and a data cache. > > Remove it. Applied to powerpc/next. [1/2] powerpc: Retire e200 core (mpc555x processor) https://git.kernel.org/powerpc/c/39c8bf2b3cc166a2a75111e4941cc5f7efbddc35 [2/2] powerpc: Remove ucache_bsize https://git.kernel.org/powerpc/c/8817aabb1bdd5811130f94ff6442bb19c9158a3a cheers
Re: [PATCH v2 1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
On Sun, 18 Oct 2020 17:25:17 + (UTC), Christophe Leroy wrote: > As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not > compatible with 440 and 460 variants. > > This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different > for 47x, meaning a kernel built for 47x will not run correctly > on a 440. > > [...] Applied to powerpc/next. [1/2] powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set https://git.kernel.org/powerpc/c/8b8319b181fd9d6821703fef1228b4dcde613a16 [2/2] powerpc/44x: Don't support 47x code and non 47x code at the same time https://git.kernel.org/powerpc/c/1f69aa0b89240653fdf708aada6a3d968447cce7 cheers
Re: [PATCH] powerpc: inline iomap accessors
On Sat, 21 Nov 2020 17:59:19 + (UTC), Christophe Leroy wrote:
> ioreadXX()/ioreadXXbe() accessors are equivalent to ppc
> in_leXX()/in_be16() accessors but they are not inlined.
>
> Since commit 0eb573682872 ("powerpc/kerenl: Enable EEH for IO
> accessors"), the 'le' versions are equivalent to the ones
> defined in asm-generic/io.h, allthough the ones there are inlined.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: inline iomap accessors
https://git.kernel.org/powerpc/c/894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e
cheers
Re: [PATCH v3 1/3] powerpc/uaccess: Don't use "m<>" constraint with GCC 4.9
On Thu, 22 Oct 2020 09:29:19 + (UTC), Christophe Leroy wrote:
> GCC 4.9 sometimes fails to build with "m<>" constraint in
> inline assembly.
>
> CC lib/iov_iter.o
> In file included from ./arch/powerpc/include/asm/cmpxchg.h:6:0,
> from ./arch/powerpc/include/asm/atomic.h:11,
> from ./include/linux/atomic.h:7,
> from ./include/linux/crypto.h:15,
> from ./include/crypto/hash.h:11,
> from lib/iov_iter.c:2:
> lib/iov_iter.c: In function 'iovec_from_user.part.30':
> ./arch/powerpc/include/asm/uaccess.h:287:2: error: 'asm' operand has
> impossible constraints
> __asm__ __volatile__(\
> ^
> ./include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
> # define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:34: note: in expansion of macro
> 'unsafe_op_wrap'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> ./arch/powerpc/include/asm/uaccess.h:329:10: note: in expansion of macro
> '__get_user_asm'
> case 4: __get_user_asm(x, (u32 __user *)ptr, retval, "lwz"); break; \
> ^
> ./arch/powerpc/include/asm/uaccess.h:363:3: note: in expansion of macro
> '__get_user_size_allowed'
>__get_user_size_allowed(__gu_val, __gu_addr, __gu_size, __gu_err); \
>^
> ./arch/powerpc/include/asm/uaccess.h:100:2: note: in expansion of macro
> '__get_user_nocheck'
> __get_user_nocheck((x), (ptr), sizeof(*(ptr)), false)
> ^
> ./arch/powerpc/include/asm/uaccess.h:583:49: note: in expansion of macro
> '__get_user_allowed'
> #define unsafe_get_user(x, p, e) unsafe_op_wrap(__get_user_allowed(x, p), e)
> ^
> lib/iov_iter.c:1663:3: note: in expansion of macro 'unsafe_get_user'
>unsafe_get_user(len, &uiov[i].iov_len, uaccess_end);
>^
> make[1]: *** [scripts/Makefile.build:283: lib/iov_iter.o] Error 1
>
> [...]
Patches 2-3 applied to powerpc/next.
[2/3] powerpc: Fix incorrect stw{, ux, u, x} instructions in __set_pte_at
https://git.kernel.org/powerpc/c/d85be8a49e733dcd23674aa6202870d54bf5600d
[3/3] powerpc: Fix update form addressing in inline assembly
https://git.kernel.org/powerpc/c/ff57698a9610fcf7d9c4469bf68c881eff22e2f8
cheers
Re: [PATCH v3 0/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
On Thu, 19 Nov 2020 17:01:54 +0100, Oleg Nesterov wrote: > Can we finally fix this problem? ;) > > My previous attempt was ignored, see > > https://lore.kernel.org/lkml/20190917121256.ga8...@redhat.com/ > > Now that gpr_get() was changed to use membuf API we can make a simpler fix. > > [...] Applied to powerpc/next. [1/2] powerpc/ptrace: Simplify gpr_get()/tm_cgpr_get() https://git.kernel.org/powerpc/c/640586f8af356096e084d69a9909d217852bde48 [2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too https://git.kernel.org/powerpc/c/324a69467f12652b21b17f9644faa967d3d8bbdf cheers
Re: [PATCH] powerpc/xmon: Change printk() to pr_cont()
On Fri, 4 Dec 2020 10:35:38 + (UTC), Christophe Leroy wrote: > Since some time now, printk() adds carriage return, leading to > unusable xmon output: > > [ 54.288722] sysrq: Entering xmon > [ 54.292209] Vector: 0 at [cace3d2c] > [ 54.292274] pc: > [ 54.292331] c0023650 > [ 54.292468] : xmon+0x28/0x58 > [ 54.292519] > [ 54.292574] lr: > [ 54.292630] c0023724 > [ 54.292749] : sysrq_handle_xmon+0xa4/0xfc > [ 54.292801] > [ 54.292867] sp: cace3de8 > [ 54.292931]msr: 9032 > [ 54.292999] current = 0xc28d > [ 54.293072] pid = 377, comm = sh > [ 54.293157] Linux version 5.10.0-rc6-s3k-dev-01364-gedf13f0ccd76-dirty > (r...@po17688vm.idsi0.si.c-s.fr) (powerpc64-linux-gcc (GCC) 10.1.0, GNU ld > (GNU Binutils) 2.34) #4211 PREEMPT Fri Dec 4 09:32:11 UTC 2020 > [ 54.293287] enter ? for help > [ 54.293470] [cace3de8] > [ 54.293532] c0023724 > [ 54.293654] sysrq_handle_xmon+0xa4/0xfc > [ 54.293711] (unreliable) > [ 54.293859] [cace3e18] > [ 54.293918] c03885a8 > [ 54.294056] __handle_sysrq+0xe4/0x1d4 > [ 54.294108] > [ 54.294255] [cace3e48] > [ 54.294314] c0388704 > [ 54.294441] write_sysrq_trigger+0x34/0x74 > [ 54.294493] > [ 54.294641] [cace3e68] > [ 54.294700] c01f65d0 > [ 54.294822] proc_reg_write+0xac/0x11c > [ 54.294875] > [ 54.295023] [cace3e88] > [ 54.295082] c0179910 > [ 54.295198] vfs_write+0x134/0x46c > [ 54.295250] > [ 54.295396] [cace3f08] > [ 54.295455] c0179de8 > [ 54.295567] ksys_write+0x78/0x11c > [ 54.295619] > [ 54.295766] [cace3f38] > [ 54.295825] c00110d0 > [ 54.295951] ret_from_syscall+0x0/0x34 > [ 54.296002] > [ 54.296159] --- Exception: c01 (System Call) at > [ 54.296217] 0fd4e784 > [ 54.296303] > [ 54.296375] SP (7fca6ff0) is in userspace > [ 54.296431] mon> > [ 54.296484] > > [...] Applied to powerpc/next. [1/1] powerpc/xmon: Change printk() to pr_cont() https://git.kernel.org/powerpc/c/7c6c86b36a36dd4a13d30bba07718e767aa2e7a1 cheers
Re: [PATCH v1 1/8] powerpc/32s: Always map kernel text and rodata with BATs
On Wed, 25 Nov 2020 07:10:46 + (UTC), Christophe Leroy wrote:
> Since commit 2b279c0348af ("powerpc/32s: Allow mapping with BATs with
> DEBUG_PAGEALLOC"), there is no real situation where mapping without
> BATs is required.
>
> In order to simplify memory handling, always map kernel text
> and rodata with BATs even when "nobats" kernel parameter is set.
>
> [...]
Applied to powerpc/next.
[1/8] powerpc/32s: Always map kernel text and rodata with BATs
https://git.kernel.org/powerpc/c/035b19a15a98907916a42a6b1d025877c42f10ad
[2/8] powerpc/32s: Don't hash_preload() kernel text
https://git.kernel.org/powerpc/c/79d1befe054ad4adb277fbd2d2756b1394eaf24e
[3/8] powerpc/32s: Fix an FTR_SECTION_ELSE
https://git.kernel.org/powerpc/c/7b107a71e732c298d684ee1bafd82f1a2be58d5e
[4/8] powerpc/32s: Don't use SPRN_SPRG_PGDIR in hash_page
https://git.kernel.org/powerpc/c/03d701c2d9b0091cf8e96cb49ab7d2a6a9f19937
[5/8] powerpc/603: Use SPRN_SDR1 to store the pgdir phys address
https://git.kernel.org/powerpc/c/c4a22611bf6ced73d86bdfc0604d7db8982a24a4
[6/8] powerpc/32: Simplify EXCEPTION_PROLOG_1 macro
https://git.kernel.org/powerpc/c/6285f9cff570bfd07b542840912c1d01bd5428e0
[7/8] powerpc/32s: Use SPRN_SPRG_SCRATCH2 in DSI prolog
https://git.kernel.org/powerpc/c/de1cd0790697e67b728de43e8657bb52f528bfb9
[8/8] powerpc/32: Use SPRN_SPRG_SCRATCH2 in exception prologs
https://git.kernel.org/powerpc/c/d2e006036082e2dc394c5ec86c5bb88cc27c0749
cheers
Re: [PATCH v2 1/2] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32
On Tue, 13 Oct 2020 11:11:20 + (UTC), Christophe Leroy wrote: > On 8xx, we get the following features: > > [0.00] cpu_features = 0x0100 > [0.00] possible= 0x0120 > [0.00] always = 0x > > This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all > other configurations, the three lines should be equal. > > [...] Patch 2 applied to powerpc/next. [2/2] powerpc/feature: Remove CPU_FTR_NODSISRALIGN https://git.kernel.org/powerpc/c/7d47034551687eb6c15e8431d897a3758fc5f83e cheers
Re: [PATCH] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro
On Fri, 27 Nov 2020 15:07:37 +0800, Youling Tang wrote: > Use the common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro rule for > the linker script in an effort. Applied to powerpc/next. [1/1] powerpc: Use common STABS_DEBUG and DWARF_DEBUG and ELF_DETAILS macro https://git.kernel.org/powerpc/c/a21df7a1d6ca9bd387a17841863a99431c4aa730 cheers
Re: [PATCH v2 0/4] Powerpc: Better preemption for shared processor
On Wed, 2 Dec 2020 10:34:52 +0530, Srikar Dronamraju wrote: > Currently, vcpu_is_preempted will return the yield_count for > shared_processor. On a PowerVM LPAR, Phyp schedules at SMT8 core boundary > i.e all CPUs belonging to a core are either group scheduled in or group > scheduled out. This can be used to better predict non-preempted CPUs on > PowerVM shared LPARs. > > perf stat -r 5 -a perf bench sched pipe -l 1000 (lesser time is better) > > [...] Applied to powerpc/next. [1/4] powerpc: Refactor is_kvm_guest() declaration to new header https://git.kernel.org/powerpc/c/92cc6bf01c7f4c5cfefd1963985c0064687ebeda [2/4] powerpc: Rename is_kvm_guest() to check_kvm_guest() https://git.kernel.org/powerpc/c/16520a858a995742c2d2248e86a6026bd0316562 [3/4] powerpc: Reintroduce is_kvm_guest() as a fast-path check https://git.kernel.org/powerpc/c/a21d1becaa3f17a97b933ffa677b526afc514ec5 [4/4] powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted() https://git.kernel.org/powerpc/c/ca3f969dcb111d35674b66bdcb72beb2c426b9b5 cheers
Re: [PATCH v1 00/30] Modernise VDSO setup
On Sun, 27 Sep 2020 09:16:16 + (UTC), Christophe Leroy wrote: > This series modernises the setup of VDSO: > - Switch to using _install_special_mapping() which has replaced > install_special_mapping() > - Move datapage in front of text like most other architectures to simplify > its localisation > - Perform link time symbol resolution instead of runtime > > This leads to a huge size reduction of vdso.c > > [...] Applied to powerpc/next. [01/30] powerpc/vdso: Stripped VDSO is not needed, don't build it https://git.kernel.org/powerpc/c/7fe2de246e21f01212a8923fbabb4ac84c944d4a [02/30] powerpc/vdso: Add missing includes and clean vdso_setup_syscall_map() https://git.kernel.org/powerpc/c/bc9d5bfc4d23fb3580e7da360f2c9bd878dda9b2 [03/30] powerpc/vdso: Rename syscall_map_32/64 to simplify vdso_setup_syscall_map() https://git.kernel.org/powerpc/c/1bb30b7a45976ae02d54fd43a8665e77314cc05e [04/30] powerpc/vdso: Remove get_page() in vdso_pagelist initialization https://git.kernel.org/powerpc/c/abcdbd039e6823305c2841d07a352fbd2343564e [05/30] powerpc/vdso: Remove NULL termination element in vdso_pagelist https://git.kernel.org/powerpc/c/35c1c7c0bc354d8c3d55bea3bf3e239797980013 [06/30] powerpc/vdso: Refactor 32 bits and 64 bits pages setup https://git.kernel.org/powerpc/c/3cf63825413c9eed2dae06070464efb27381bdac [07/30] powerpc/vdso: Remove unnecessary ifdefs in vdso_pagelist initialization https://git.kernel.org/powerpc/c/4fe0e3c1724e397845df75f64059bcea4ff590e8 [08/30] powerpc/vdso: Use VDSO size in arch_setup_additional_pages() https://git.kernel.org/powerpc/c/7461a4f79ba16dc7733c07c00883a10c7e46b602 [09/30] powerpc/vdso: Simplify arch_setup_additional_pages() exit https://git.kernel.org/powerpc/c/b2df3f60b452ab496adcef1b2f9c2560f6d8e8e0 [10/30] powerpc/vdso: Move to _install_special_mapping() and remove arch_vma_name() https://git.kernel.org/powerpc/c/c1bab64360e6850ca54305d2f1902dac829c9752 [11/30] powerpc/vdso: Provide vdso_remap() https://git.kernel.org/powerpc/c/526a9c4a7234cccf6d900c6e82d79356f974cbfd [12/30] powerpc/vdso: Replace vdso_base by vdso https://git.kernel.org/powerpc/c/c102f07667486dc4a6ae1e3fe7aa67135cb40e3e [13/30] powerpc/vdso: Move vdso datapage up front https://git.kernel.org/powerpc/c/511157ab641eb6bedd00d62673388e78a4f871cf [14/30] powerpc/vdso: Simplify __get_datapage() https://git.kernel.org/powerpc/c/591857b635c1f635cae556e1b1f9d81808242493 [15/30] powerpc/vdso: Remove unused \tmp param in __get_datapage() https://git.kernel.org/powerpc/c/550e6074c106e1a6fb57dfef62f0daede12d832c [16/30] powerpc/vdso: Retrieve sigtramp offsets at buildtime https://git.kernel.org/powerpc/c/91bf695596f594e42d69d70deb2ae53cafecf77c [17/30] powerpc/vdso: Use builtin symbols to locate fixup section https://git.kernel.org/powerpc/c/ed07f6353ddf19e51c4db6d2be72ca97f7ed8a08 [18/30] powerpc/vdso: Merge __kernel_sync_dicache_p5() into __kernel_sync_dicache() https://git.kernel.org/powerpc/c/0fc980db9a404a993c4ed542369a745d8a14b0b7 [19/30] powerpc/vdso: Remove vdso32_pages and vdso64_pages https://git.kernel.org/powerpc/c/b7fe9c15b57d767fda250e8eff79be435996ef33 [20/30] powerpc/vdso: Remove __kernel_datapage_offset https://git.kernel.org/powerpc/c/49bf59fd0371b1053a17021f27605f43071584ee [21/30] powerpc/vdso: Remove runtime generated sigtramp offsets https://git.kernel.org/powerpc/c/899367ea50637f382fdc5c927fe47e6090d4aefe [22/30] powerpc/vdso: Remove vdso_patches[] and associated functions https://git.kernel.org/powerpc/c/5cda7c75493fd17a010d7399e39fda6619f69043 [23/30] powerpc/vdso: Remove unused text member in struct lib32/64_elfinfo https://git.kernel.org/powerpc/c/e113f8ef1c7e5fd79b440e5565c8552b36122bfa [24/30] powerpc/vdso: Remove symbol section information in struct lib32/64_elfinfo https://git.kernel.org/powerpc/c/6ed613ad572a84c175629fc8657a197c6415b7d6 [25/30] powerpc/vdso: Remove lib32_elfinfo and lib64_elfinfo https://git.kernel.org/powerpc/c/67a354051da28d482e53146def212b102664ce0e [26/30] powerpc/vdso: Remove vdso_setup() https://git.kernel.org/powerpc/c/a4ccd64acb8c08ce8d36001cdd06477deec6ae89 [27/30] powerpc/vdso: Remove vdso_ready https://git.kernel.org/powerpc/c/23c4ceaf1a457808d031c666760fa325c7b7f23f [28/30] powerpc/vdso: Remove DBG() https://git.kernel.org/powerpc/c/e90903203d94d0a0d0e8ebc979aa0617a7bbe9a3 [29/30] powerpc/vdso: Remove VDSO32_LBASE and VDSO64_LBASE https://git.kernel.org/powerpc/c/676155ab239dc2035d5306438b45695b6fa165e2 [30/30] powerpc/vdso: Cleanup vdso.h https://git.kernel.org/powerpc/c/65d2150c89121a49e4bd4abbb99c436c77003eed cheers
Re: [PATCH] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2
On Mon, 12 Oct 2020 08:04:24 + (UTC), Christophe Leroy wrote: > MMU_FTR_PPCAS_ARCH_V2 is defined in cpu_table.h > as MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE. > > MMU_FTR_TLBIEL and MMU_FTR_16M_PAGE are defined in mmu.h > > MMU_FTR_PPCAS_ARCH_V2 is used only in mmu.h and it is used only once. > > [...] Applied to powerpc/next. [1/1] powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2 https://git.kernel.org/powerpc/c/0e8ff4f8d2faa2e3381e774c9e2fb975e8b4598f cheers
Re: [PATCH v2] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
On Mon, 7 Dec 2020 16:58:01 + (UTC), Christophe Leroy wrote:
> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
> routines"), userspace access is not granted anymore when using
> copy_from_kernel_nofault()
>
> However, kthread_probe_data() uses copy_from_kernel_nofault()
> to check validity of pointers. When the pointer is NULL,
> it points to userspace, leading to a KUAP fault and triggering
> the following big hammer warning many times when you request
> a sysrq "show task":
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm: Fix KUAP warning by providing
copy_from_kernel_nofault_allowed()
https://git.kernel.org/powerpc/c/5eedf9fe8db23313df104576845cec5f481b9b60
cheers
Re: [PATCH v1 2/6] powerpc/8xx: Always pin kernel text TLB
Christophe Leroy writes: > Le 09/12/2020 à 11:43, Michael Ellerman a écrit : >> Christophe Leroy writes: >>> There is no big poing in not pinning kernel text anymore, as now >>> we can keep pinned TLB even with things like DEBUG_PAGEALLOC. >>> >>> Remove CONFIG_PIN_TLB_TEXT, making it always right. >>> >>> Signed-off-by: Christophe Leroy >>> --- >>> arch/powerpc/Kconfig | 3 +-- >>> arch/powerpc/kernel/head_8xx.S | 20 +++- >>> arch/powerpc/mm/nohash/8xx.c | 3 +-- >>> arch/powerpc/platforms/8xx/Kconfig | 7 --- >>> 4 files changed, 5 insertions(+), 28 deletions(-) >>> >> ... >>> diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c >>> index 231ca95f9ffb..19a3eec1d8c5 100644 >>> --- a/arch/powerpc/mm/nohash/8xx.c >>> +++ b/arch/powerpc/mm/nohash/8xx.c >>> @@ -186,8 +186,7 @@ void mmu_mark_initmem_nx(void) >>> mmu_mapin_ram_chunk(0, boundary, PAGE_KERNEL_TEXT, false); >>> mmu_mapin_ram_chunk(boundary, einittext8, PAGE_KERNEL, false); >>> >>> - if (IS_ENABLED(CONFIG_PIN_TLB_TEXT)) >>> - mmu_pin_tlb(block_mapped_ram, false); >>> + mmu_pin_tlb(block_mapped_ram, false); >>> } >> >> This broke mpc885_ads_defconfig with: > > :surprise: > > How did I get it working ? Anyway, thanks for fixing it. No worries. I figured you must have tested with some other series(s) applied and/or with different configs, it happens :) cheers
Re: linux-next: build warning after merge of the akpm tree
Stephen Rothwell writes: > Hi Michael, > > On Wed, 09 Dec 2020 15:44:35 +1100 Michael Ellerman > wrote: >> >> They should really be in DATA_DATA or similar shouldn't they? > > No other architecture appears t need them ... Any arch with orphan-handling=warn should see them I thought? cheers
Re: [PATCH v1 2/6] powerpc/8xx: Always pin kernel text TLB
Christophe Leroy writes: > There is no big poing in not pinning kernel text anymore, as now > we can keep pinned TLB even with things like DEBUG_PAGEALLOC. > > Remove CONFIG_PIN_TLB_TEXT, making it always right. > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/Kconfig | 3 +-- > arch/powerpc/kernel/head_8xx.S | 20 +++- > arch/powerpc/mm/nohash/8xx.c | 3 +-- > arch/powerpc/platforms/8xx/Kconfig | 7 --- > 4 files changed, 5 insertions(+), 28 deletions(-) > ... > diff --git a/arch/powerpc/mm/nohash/8xx.c b/arch/powerpc/mm/nohash/8xx.c > index 231ca95f9ffb..19a3eec1d8c5 100644 > --- a/arch/powerpc/mm/nohash/8xx.c > +++ b/arch/powerpc/mm/nohash/8xx.c > @@ -186,8 +186,7 @@ void mmu_mark_initmem_nx(void) > mmu_mapin_ram_chunk(0, boundary, PAGE_KERNEL_TEXT, false); > mmu_mapin_ram_chunk(boundary, einittext8, PAGE_KERNEL, false); > > - if (IS_ENABLED(CONFIG_PIN_TLB_TEXT)) > - mmu_pin_tlb(block_mapped_ram, false); > + mmu_pin_tlb(block_mapped_ram, false); > } This broke mpc885_ads_defconfig with: ld: arch/powerpc/mm/nohash/8xx.o: in function `mmu_mark_initmem_nx': /home/michael/linux/arch/powerpc/mm/nohash/8xx.c:189: undefined reference to `mmu_pin_tlb' make[1]: *** [/home/michael/linux/Makefile:1164: vmlinux] Error 1 make: *** [Makefile:185: __sub-make] Error 2 Fixed by: diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 35707e86c5f3..52702f3db6df 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -702,7 +702,6 @@ FixupDAR:/* Entry point for dcbx workaround. */ mtspr SPRN_DER, r8 blr -#ifdef CONFIG_PIN_TLB _GLOBAL(mmu_pin_tlb) lis r9, (1f - PAGE_OFFSET)@h ori r9, r9, (1f - PAGE_OFFSET)@l @@ -802,7 +801,6 @@ _GLOBAL(mmu_pin_tlb) mtspr SPRN_SRR1, r10 mtspr SPRN_SRR0, r11 rfi -#endif /* CONFIG_PIN_TLB */ /* * We put a few things here that have to be page-aligned. cheers
Re: linux-next: build warning after merge of the akpm tree
Stephen Rothwell writes:
> Hi Stephen,
>
> On Fri, 4 Dec 2020 21:00:00 +1100 Stephen Rothwell
> wrote:
>>
>> Hi all,
>>
>> After merging the akpm tree, today's linux-next build (powerpc
>> allyesconfig) produced warnings like this:
>>
>> ld: warning: orphan section `.data..Lubsan_data177' from
>> `arch/powerpc/oprofile/op_model_pa6t.o' being placed in section
>> `.data..Lubsan_data177'
>>
>> (lots of these latter ones)
>
> 781584 of them today!
>
>> I don't know what produced these, but it is in the akpm-current or
>> akpm trees.
>
> Presumably the result of commit
>
> 186c3e18dba3 ("ubsan: enable for all*config builds")
>
> from the akpm-current tree.
>
> arch/powerpc/kernel/vmlinux.lds.S has:
>
> #ifdef CONFIG_PPC32
> .data : AT(ADDR(.data) - LOAD_OFFSET) {
> DATA_DATA
> #ifdef CONFIG_UBSAN
> *(.data..Lubsan_data*)
> *(.data..Lubsan_type*)
> #endif
> *(.data.rel*)
> *(SDATA_MAIN)
>
> added by commit
>
> beba24ac5913 ("powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type*
> sections explicitly")
>
> in 2018, but no equivalent for 64 bit.
They should really be in DATA_DATA or similar shouldn't they?
cheers
Re: [PATCH 1/3] powerpc/smp: Parse ibm,thread-groups with multiple properties
Gautham R Shenoy writes:
> Hello Srikar,
>
> Thanks for taking a look at the patch.
>
> On Mon, Dec 07, 2020 at 05:40:42PM +0530, Srikar Dronamraju wrote:
>> * Gautham R. Shenoy [2020-12-04 10:18:45]:
>>
>> > From: "Gautham R. Shenoy"
>>
>>
>>
>> >
>> > static int parse_thread_groups(struct device_node *dn,
>> > - struct thread_groups *tg,
>> > - unsigned int property)
>> > + struct thread_groups_list *tglp)
>> > {
>> > - int i;
>> > - u32 thread_group_array[3 + MAX_THREAD_LIST_SIZE];
>> > + int i = 0;
>> > + u32 *thread_group_array;
>> >u32 *thread_list;
>> >size_t total_threads;
>> > - int ret;
>> > + int ret = 0, count;
>> > + unsigned int property_idx = 0;
>>
>> NIT:
>> tglx mentions in one of his recent comments to try keep a reverse fir tree
>> ordering of variables where possible.
>
> I suppose you mean moving the longer local variable declarations to to
> the top and shorter ones to the bottom. Thanks. Will fix this.
Yeah. It's called "reverse christmas tree", that's googleable.
I also prefer that style, it makes the locals visually sit with the
beginning of the function body.
cheers
Re: [PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver
Borislav Petkov writes:
> On Mon, Dec 07, 2020 at 03:02:53PM +1100, Michael Ellerman wrote:
>> The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is
>> not user-selectable, and the last code that selected it was removed
>> with the C2K board support in 2018, see:
>>
>> 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
>>
>> That means the driver is now dead code, so remove it.
>>
>> Suggested-by: Borislav Petkov
>> Signed-off-by: Michael Ellerman
>> ---
>> drivers/edac/Kconfig| 7 -
>> drivers/edac/Makefile | 1 -
>> drivers/edac/mv64x60_edac.c | 883
>> drivers/edac/mv64x60_edac.h | 114 -
>> 4 files changed, 1005 deletions(-)
>> delete mode 100644 drivers/edac/mv64x60_edac.c
>> delete mode 100644 drivers/edac/mv64x60_edac.h
>
> Gladly taken and applied, thanks!
Thanks.
cheers
Re: [PATCH] arch: fix 'unexpected IRQ trap at vector' warnings
"Enrico Weigelt, metux IT consult" writes:
> All archs, except Alpha, print out the irq number in hex, but the message
> looks like it was a decimal number, which is quite confusing. Fixing this
> by adding "0x" prefix.
Arguably decimal would be better, /proc/interrupts and /proc/irq/ both
use decimal.
The whole message is very dated IMO, these days the number it prints is
(possibly) virtualised via IRQ domains, ie. it's not necessarily a
"vector" if that even makes sense on all arches). Arguably "trap" is the
wrong term on some arches too.
So it would be better reworded entirely IMO, and also switched to
decimal to match other sources of information on interrupts.
Perhaps:
"Unexpected Linux IRQ %d."
If anyone else is having deja vu like me, yes this has come up before:
https://lore.kernel.org/lkml/20150712220211.7166.42035.st...@bhelgaas-glaptop2.roam.corp.google.com/
cheers
> diff --git a/arch/arm/include/asm/hw_irq.h b/arch/arm/include/asm/hw_irq.h
> index cecc13214ef1..2749f19271d9 100644
> --- a/arch/arm/include/asm/hw_irq.h
> +++ b/arch/arm/include/asm/hw_irq.h
> @@ -9,7 +9,7 @@ static inline void ack_bad_irq(int irq)
> {
> extern unsigned long irq_err_count;
> irq_err_count++;
> - pr_crit("unexpected IRQ trap at vector %02x\n", irq);
> + pr_crit("unexpected IRQ trap at vector 0x%02x\n", irq);
> }
>
> #define ARCH_IRQ_INIT_FLAGS (IRQ_NOREQUEST | IRQ_NOPROBE)
> diff --git a/arch/parisc/include/asm/hardirq.h
> b/arch/parisc/include/asm/hardirq.h
> index 7f7039516e53..c3348af88d3f 100644
> --- a/arch/parisc/include/asm/hardirq.h
> +++ b/arch/parisc/include/asm/hardirq.h
> @@ -35,6 +35,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
> #define __IRQ_STAT(cpu, member) (irq_stat[cpu].member)
> #define inc_irq_stat(member) this_cpu_inc(irq_stat.member)
> #define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member)
> -#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", irq)
> +#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector 0x%02x\n",
> irq)
>
> #endif /* _PARISC_HARDIRQ_H */
> diff --git a/arch/powerpc/include/asm/hardirq.h
> b/arch/powerpc/include/asm/hardirq.h
> index f133b5930ae1..ec8cf3cf6e49 100644
> --- a/arch/powerpc/include/asm/hardirq.h
> +++ b/arch/powerpc/include/asm/hardirq.h
> @@ -29,7 +29,7 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
>
> static inline void ack_bad_irq(unsigned int irq)
> {
> - printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
> + printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
> }
>
> extern u64 arch_irq_stat_cpu(unsigned int cpu);
> diff --git a/arch/s390/include/asm/hardirq.h b/arch/s390/include/asm/hardirq.h
> index dfbc3c6c0674..aaaec5cdd4fe 100644
> --- a/arch/s390/include/asm/hardirq.h
> +++ b/arch/s390/include/asm/hardirq.h
> @@ -23,7 +23,7 @@
>
> static inline void ack_bad_irq(unsigned int irq)
> {
> - printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
> + printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
> }
>
> #endif /* __ASM_HARDIRQ_H */
> diff --git a/arch/um/include/asm/hardirq.h b/arch/um/include/asm/hardirq.h
> index b426796d26fd..2a2e6eae034b 100644
> --- a/arch/um/include/asm/hardirq.h
> +++ b/arch/um/include/asm/hardirq.h
> @@ -15,7 +15,7 @@ typedef struct {
> #ifndef ack_bad_irq
> static inline void ack_bad_irq(unsigned int irq)
> {
> - printk(KERN_CRIT "unexpected IRQ trap at vector %02x\n", irq);
> + printk(KERN_CRIT "unexpected IRQ trap at vector 0x%02x\n", irq);
> }
> #endif
>
> diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
> index c5dd50369e2f..957c716f2df7 100644
> --- a/arch/x86/kernel/irq.c
> +++ b/arch/x86/kernel/irq.c
> @@ -37,7 +37,7 @@ atomic_t irq_err_count;
> void ack_bad_irq(unsigned int irq)
> {
> if (printk_ratelimit())
> - pr_err("unexpected IRQ trap at vector %02x\n", irq);
> + pr_err("unexpected IRQ trap at vector 0x%02x\n", irq);
>
> /*
>* Currently unexpected vectors happen only on SMP and APIC.
> --
> 2.11.0
Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
Christophe Leroy writes:
> Le 07/12/2020 à 01:24, Michael Ellerman a écrit :
>> Christophe Leroy writes:
>>> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
>>> routines"), userspace access is not granted anymore when using
>>> copy_from_kernel_nofault()
>>>
>>> However, kthread_probe_data() uses copy_from_kernel_nofault()
>>> to check validity of pointers. When the pointer is NULL,
>>> it points to userspace, leading to a KUAP fault and triggering
>>> the following big hammer warning many times when you request
>>> a sysrq "show task":
>>>
>>> [ 1117.202054] [ cut here ]
>>> [ 1117.202102] Bug: fault blocked by AP register !
>>> [ 1117.202261] WARNING: CPU: 0 PID: 377 at
>>> arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
>>> [ 1117.202310] Modules linked in:
>>> [ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: GW
>>> 5.10.0-rc5-01340-g83f53be2de31-dirty #4175
>>> [ 1117.202499] NIP: c0012048 LR: c0012048 CTR:
>>> [ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: GW
>>> (5.10.0-rc5-01340-g83f53be2de31-dirty)
>>> [ 1117.202625] MSR: 00021032 CR: 2408 XER: 2000
>>> [ 1117.202899]
>>> [ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 0023 c092e554 0001
>>> c09865e8 c092e640
>>> [ 1117.202899] GPR08: 1032 00014efc 28082224 100d166a
>>> 100a0920
>>> [ 1117.202899] GPR16: 100cac0c 100b 1080c3fc 1080d685 100d 100d
>>> 100a0900
>>> [ 1117.202899] GPR24: 100d c07892ec c0921510 c21f4440 005c
>>> c000 cacdbc80
>>> [ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
>>> [ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
>>> [ 1117.204509] Call Trace:
>>> [ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
>>> [ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
>>> [ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
>>> [ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 0001
>>> [ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: GW
>>> (5.10.0-rc5-01340-g83f53be2de31-dirty)
>>> [ 1117.205104] MSR: 9032 CR: 28082224 XER:
>>> [ 1117.205416] DAR: 005c DSISR: c000
>>> [ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 0001 0017 0017
>>> 0027 000f
>>> [ 1117.205416] GPR08: c09926ec 3000 24082224
>>> [ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
>>> [ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
>>> [ 1117.206258] --- interrupt: 301
>>> [ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70
>>> (unreliable)
>>> [ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
>>> [ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
>>> [ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
>>> [ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
>>> [ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
>>> [ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
>>> [ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
>>> [ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
>>> [ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
>>> [ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
>>> [ 1117.207938] --- interrupt: c01 at 0xfd4e784
>>> [ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
>>> [ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: GW
>>> (5.10.0-rc5-01340-g83f53be2de31-dirty)
>>> [ 1117.208134] MSR: d032 CR: 4400 XER:
>>>
>>> [ 1117.208470]
>>> [ 1117.208470] GPR00: 0004 7fc34090 77bfb4e0 0001 1080fa40 0002
>>> 740f fefefeff
>>> [ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0
>>> [ 1117.209104] NIP [0fd4e784] 0xfd4e784
>>> [ 1117.209180] LR [0fe0f244] 0xfe0f244
>>> [ 1117.209236] --- interrupt: c01
>>> [ 1117.209274] Instruction dump:
>>> [ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8
>>> 73c90040 4082ff60
>>> [ 1117.209727] 0fe0 3c60c082 386399f4 48013b65 <0fe0> 80010034
>>> 38600
[PATCH] EDAC/mv64x60: Remove orphan mv64x60 driver
The mv64x60 EDAC driver depends on CONFIG_MV64X60. But that symbol is
not user-selectable, and the last code that selected it was removed
with the C2K board support in 2018, see:
92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
That means the driver is now dead code, so remove it.
Suggested-by: Borislav Petkov
Signed-off-by: Michael Ellerman
---
drivers/edac/Kconfig| 7 -
drivers/edac/Makefile | 1 -
drivers/edac/mv64x60_edac.c | 883
drivers/edac/mv64x60_edac.h | 114 -
4 files changed, 1005 deletions(-)
delete mode 100644 drivers/edac/mv64x60_edac.c
delete mode 100644 drivers/edac/mv64x60_edac.h
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index fa0c3b5797e4..f3816f1131ed 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -292,13 +292,6 @@ config EDAC_LAYERSCAPE
Support for error detection and correction on Freescale memory
controllers on Layerscape SoCs.
-config EDAC_MV64X60
- tristate "Marvell MV64x60"
- depends on MV64X60
- help
- Support for error detection and correction on the Marvell
- MV64360 and MV64460 chipsets.
-
config EDAC_PASEMI
tristate "PA Semi PWRficient"
depends on PPC_PASEMI && PCI
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index 3cd1aeb0a916..464d3d8d850a 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -65,7 +65,6 @@ obj-$(CONFIG_EDAC_SKX)+= skx_edac.o
i10nm_edac-y := skx_common.o i10nm_base.o
obj-$(CONFIG_EDAC_I10NM) += i10nm_edac.o
-obj-$(CONFIG_EDAC_MV64X60) += mv64x60_edac.o
obj-$(CONFIG_EDAC_CELL)+= cell_edac.o
obj-$(CONFIG_EDAC_PPC4XX) += ppc4xx_edac.o
obj-$(CONFIG_EDAC_AMD8111) += amd8111_edac.o
diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
deleted file mode 100644
index 3c68bb525d5d..
--- a/drivers/edac/mv64x60_edac.c
+++ /dev/null
@@ -1,883 +0,0 @@
-/*
- * Marvell MV64x60 Memory Controller kernel module for PPC platforms
- *
- * Author: Dave Jiang
- *
- * 2006-2007 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "edac_module.h"
-#include "mv64x60_edac.h"
-
-static const char *mv64x60_ctl_name = "MV64x60";
-static int edac_dev_idx;
-static int edac_pci_idx;
-static int edac_mc_idx;
-
-/*** PCI err device **/
-#ifdef CONFIG_PCI
-static void mv64x60_pci_check(struct edac_pci_ctl_info *pci)
-{
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 cause;
-
- cause = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!cause)
- return;
-
- printk(KERN_ERR "Error in PCI %d Interface\n", pdata->pci_hose);
- printk(KERN_ERR "Cause register: 0x%08x\n", cause);
- printk(KERN_ERR "Address Low: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_LO));
- printk(KERN_ERR "Address High: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ADDR_HI));
- printk(KERN_ERR "Attribute: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_ATTR));
- printk(KERN_ERR "Command: 0x%08x\n",
- readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CMD));
- writel(~cause, pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
-
- if (cause & MV64X60_PCI_PE_MASK)
- edac_pci_handle_pe(pci, pci->ctl_name);
-
- if (!(cause & MV64X60_PCI_PE_MASK))
- edac_pci_handle_npe(pci, pci->ctl_name);
-}
-
-static irqreturn_t mv64x60_pci_isr(int irq, void *dev_id)
-{
- struct edac_pci_ctl_info *pci = dev_id;
- struct mv64x60_pci_pdata *pdata = pci->pvt_info;
- u32 val;
-
- val = readl(pdata->pci_vbase + MV64X60_PCI_ERROR_CAUSE);
- if (!val)
- return IRQ_NONE;
-
- mv64x60_pci_check(pci);
-
- return IRQ_HANDLED;
-}
-
-/*
- * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
- * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
- * well. IOW, don't set bit 0.
- */
-
-/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
-static int __init mv64x60_pci_fixup(struct platform_device *pdev)
-{
- struct resource *r;
- void __iomem *pci_serr;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!r) {
- printk(KERN_ERR "%s:
Re: [PATCH] powerpc/mm: Fix KUAP warning by providing copy_from_kernel_nofault_allowed()
Christophe Leroy writes:
> Since commit c33165253492 ("powerpc: use non-set_fs based maccess
> routines"), userspace access is not granted anymore when using
> copy_from_kernel_nofault()
>
> However, kthread_probe_data() uses copy_from_kernel_nofault()
> to check validity of pointers. When the pointer is NULL,
> it points to userspace, leading to a KUAP fault and triggering
> the following big hammer warning many times when you request
> a sysrq "show task":
>
> [ 1117.202054] [ cut here ]
> [ 1117.202102] Bug: fault blocked by AP register !
> [ 1117.202261] WARNING: CPU: 0 PID: 377 at
> arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
> [ 1117.202310] Modules linked in:
> [ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: GW
> 5.10.0-rc5-01340-g83f53be2de31-dirty #4175
> [ 1117.202499] NIP: c0012048 LR: c0012048 CTR:
> [ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.202625] MSR: 00021032 CR: 2408 XER: 2000
> [ 1117.202899]
> [ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 0023 c092e554 0001
> c09865e8 c092e640
> [ 1117.202899] GPR08: 1032 00014efc 28082224 100d166a
> 100a0920
> [ 1117.202899] GPR16: 100cac0c 100b 1080c3fc 1080d685 100d 100d
> 100a0900
> [ 1117.202899] GPR24: 100d c07892ec c0921510 c21f4440 005c
> c000 cacdbc80
> [ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204509] Call Trace:
> [ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
> [ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
> [ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 0001
> [ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.205104] MSR: 9032 CR: 28082224 XER:
> [ 1117.205416] DAR: 005c DSISR: c000
> [ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 0001 0017 0017
> 0027 000f
> [ 1117.205416] GPR08: c09926ec 3000 24082224
> [ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
> [ 1117.206258] --- interrupt: 301
> [ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
> [ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
> [ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
> [ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
> [ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
> [ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
> [ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
> [ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
> [ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
> [ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
> [ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
> [ 1117.207938] --- interrupt: c01 at 0xfd4e784
> [ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
> [ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: GW
> (5.10.0-rc5-01340-g83f53be2de31-dirty)
> [ 1117.208134] MSR: d032 CR: 4400 XER:
> [ 1117.208470]
> [ 1117.208470] GPR00: 0004 7fc34090 77bfb4e0 0001 1080fa40 0002
> 740f fefefeff
> [ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0
> [ 1117.209104] NIP [0fd4e784] 0xfd4e784
> [ 1117.209180] LR [0fe0f244] 0xfe0f244
> [ 1117.209236] --- interrupt: c01
> [ 1117.209274] Instruction dump:
> [ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040
> 4082ff60
> [ 1117.209727] 0fe0 3c60c082 386399f4 48013b65 <0fe0> 80010034
> 386b 7c0803a6
> [ 1117.210102] ---[ end trace 1927c0323393af3e ]---
>
> To avoid that, copy_from_kernel_nofault_allowed() is used to check
> whether the address is a valid kernel address. But the default
> version of it returns true for any address.
>
> Provide a powerpc version of copy_from_kernel_nofault_allowed()
> that returns false when the address is below TASK_USER_MAX,
> so that copy_from_kernel_nofault() will return -ERANGE.
>
> Reported-by: Qian Cai
> Fixes: c33165253492 ("powerpc: use non-set_fs based maccess routines")
> Cc: Christoph Hellwig
> Cc: Al Viro
> Signed-off-by: Christophe Leroy
> ---
> This issue was introduced in 5.10. I didn't mark it for stable, hopping it
> will go into 5.10-rc7
> ---
> arch/powerpc/mm/Makefile | 2 +-
> arch/powerpc/mm/maccess.c | 9 +
> 2 files changed, 10 insertions(+), 1 deletion(-)
> create mode 100644 arch/powerpc/mm/maccess.c
>
> diff --git a/arch/powerpc/mm/maccess.c b/arch/powerpc/mm/maccess.c
[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-5 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.10. The change to kernel/cpu.c is just adding an optional arch override, and has Peter's ack. cheers The following changes since commit b6b79dd53082db11070b4368d85dd6699ff0b063: powerpc/64s: Fix allnoconfig build since uaccess flush (2020-11-23 21:16:42 +1100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.10-5 for you to fetch changes up to a1ee28117077c3bf24e5ab6324c835eaab629c45: powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE (2020-12-02 23:16:40 +1100) - -- powerpc fixes for 5.10 #5 Three commits fixing possible missed TLB invalidations for multi-threaded processes when CPUs are hotplugged in and out. A fix for a host crash triggerable by host userspace (qemu) in KVM on Power9. A fix for a host crash in machine check handling when running HPT guests on a HPT host. One commit fixing potential missed TLB invalidations when using the hash MMU on Power9 or later. A regression fix for machines with CPUs on node 0 but no memory. Thanks to: Aneesh Kumar K.V, Cédric Le Goater, Greg Kurz, Milan Mohanty, Milton Miller, Nicholas Piggin, Paul Mackerras, Srikar Dronamraju. - -- Greg Kurz (1): KVM: PPC: Book3S HV: XIVE: Fix vCPU id sanity check Nicholas Piggin (5): powerpc/64s: Fix hash ISA v3.0 TLBIEL instruction generation powerpc/64s/pseries: Fix hash tlbiel_all_isa300 for guest kernels kernel/cpu: add arch override for clear_tasks_mm_cpumask() mm handling powerpc/64s: Trim offlined CPUs from mm_cpumasks powerpc/64s/powernv: Fix memory corruption when saving SLB entries on MCE Srikar Dronamraju (1): powerpc/numa: Fix a regression on memoryless node 0 arch/powerpc/include/asm/book3s/64/mmu.h | 12 ++ arch/powerpc/kvm/book3s_xive.c | 7 ++ arch/powerpc/mm/book3s64/hash_native.c | 23 +--- arch/powerpc/mm/book3s64/mmu_context.c | 20 + arch/powerpc/mm/numa.c | 3 +-- arch/powerpc/platforms/powermac/smp.c| 2 ++ arch/powerpc/platforms/powernv/setup.c | 9 ++-- arch/powerpc/platforms/powernv/smp.c | 3 +++ arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 +++ kernel/cpu.c | 6 - 10 files changed, 70 insertions(+), 18 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/Ler0ACgkQUevqPMjh pYBdSg//YL+3GipNsfXCyKfCXxlVn3/v6e+tAa4EYrJc7BxHWq2rr4tCO5ycsZPg yGPRNFDKPlN8jP/qX29LjKF4k1D9uQ7Z/FL1MM7Z3Xrwu5lOZJn2AYbKUrLIN1jX IfddqmH5FuGXC+9GPXDo8OT0IZzzp4HNvqUAFMfgulH4IHkFCmBx3+bjQxRbprmA c3bikk4GR/qEP97RIVga8MZOnnt8LccS86iH81/d5jT8zMgL61FGCqGdkinTDSIt 4Qo4jrSj2zhbZs8gsff7ZbDvKfe/tNUClzvyFoi40hbSQogPE+r/Ik1ol9snxSdv YYWwX1Yov2n10FOoqVsK4m5EWfx988+uyJ6on9pOYR0IJIZQ0GkaQ+5HptgGsTR6 5sRW6uiHxpaABhSZPaBcgH09G2ppjBlFC2Hz2g9NZuCCckdHx+FdrG+MGHMq+KRT hSZafOosPSPLyqDlUDo9RuksBEk/oOkO2beizVfGo2ETx6AQO3zzrhQcA/kU9Gxy opFfBP5sikmesAXxP0fxd0tg20EkRlWZzEDu/dFNhbNW+T0/KwzYuZaGsf7l65GO XpyiLScm4a0vSIt481eqMd4oazrYFIPGZgTU10ws6lI7DM9q360Zhn5VOf80i4Lw fYorXpe7KILB6PveChkJ+DiR/2UPRrzWSKoZ4SfQfJwzQKp4Td8= =N1fr -END PGP SIGNATURE-
Re: WARN_ON_ONCE
Alexey Kardashevskiy writes:
> On 04/12/2020 12:25, Michael Ellerman wrote:
>> Dmitry Vyukov writes:
>>> On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
>>>> On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy
>>>> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> Syzkaller triggered WARN_ON_ONCE at
>>>>>
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/tracepoint.c?h=v5.10-rc6#n266
>>>>>
>>>>>
>>>>> ===
>>>>> static int tracepoint_add_func(struct tracepoint *tp,
>>>>> struct tracepoint_func *func, int prio)
>>>>> {
>>>>> struct tracepoint_func *old, *tp_funcs;
>>>>> int ret;
>>>>>
>>>>> if (tp->regfunc && !static_key_enabled(&tp->key)) {
>>>>> ret = tp->regfunc();
>>>>> if (ret < 0)
>>>>> return ret;
>>>>> }
>>>>>
>>>>> tp_funcs = rcu_dereference_protected(tp->funcs,
>>>>> lockdep_is_held(&tracepoints_mutex));
>>>>> old = func_add(&tp_funcs, func, prio);
>>>>> if (IS_ERR(old)) {
>>>>> WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
>>>>> return PTR_ERR(old);
>>>>> }
>>>>>
>>>>> ===
>>>>>
>>>>> What is the common approach here? Syzkaller reacts on this as if it was
>>>>> a bug but WARN_ON_ONCE here seems intentional. Do we still push for
>>>>> removing such warnings?
>>
>> AFAICS it is a bug if that fires.
>>
>> See the commit that added it:
>>d66a270be331 ("tracepoint: Do not warn on ENOMEM")
>>
>> Which says:
>>Tracepoint should only warn when a kernel API user does not respect the
>>required preconditions (e.g. same tracepoint enabled twice,
>
> This says that the userspace can trigger the warning if it does not use
> the API right.
No I don't think it says that.
It's saying that it should be a WARN if a *kernel* user of the
tracepoint API violates the API. The implication is that this condition
should never happen if the kernel is using the tracepoint API correctly,
and so if we hit this condition it indicates a bug in the kernel that
should be fixed.
>> or called
>>to remove a tracepoint that does not exist).
>>
>>Silence warning in out-of-memory conditions, given that the error is
>>returned to the caller.
>>
>>
>> So if you're seeing it then you've someone caused it to return something
>> other than ENOMEM, and that is a bug.
>
> This is an userspace bug which registers the same thing twice, the
> kernel returns a correct error. The question is should it warn by
> WARN_ON or pr_err(). The comment in bug.h suggests pr_err() is the right
> way, is not it?
Userspace must not be able to trigger a WARN.
What is the path into that code from userspace?
Either something on that path should be checking that it's not violating
the API and triggering the WARN, or if that's not possible/easy then the
WARN should be removed.
cheers
Re: [PATCH] MAINTAINERS: Update 68k Mac entry
Finn Thain writes: > Two files under drivers/macintosh are actually m68k-only. I think that > patches for these files should be reviewed in the appropriate forum and > merged via the appropriate tree, rather than falling to the powerpc > maintainers to deal with. Update the "M68K ON APPLE MACINTOSH" section > accordingly. > > Cc: Michael Ellerman > Cc: Benjamin Herrenschmidt > Cc: Joshua Thompson > Cc: linuxppc-...@lists.ozlabs.org > Cc: linux-m...@lists.linux-m68k.org > Signed-off-by: Finn Thain > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Michael Ellerman cheers > diff --git a/MAINTAINERS b/MAINTAINERS > index 867157311dc8..e8fa0c9645d6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10322,6 +10322,8 @@ L:linux-m...@lists.linux-m68k.org > S: Maintained > W: http://www.mac.linux-m68k.org/ > F: arch/m68k/mac/ > +F: drivers/macintosh/adb-iop.c > +F: drivers/macintosh/via-macii.c > > M68K ON HP9000/300 > M: Philip Blundell > -- > 2.26.2
Re: [PATCH] powerpc: Stop exporting __clear_user which is now inlined.
Michal Suchanek writes:
> Stable commit 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP
> enabled") redefines __clear_user as inline function but does not remove
> the export.
>
> Fixes: 452e2a83ea23 ("powerpc: Fix __clear_user() with KUAP enabled")
>
> Signed-off-by: Michal Suchanek
> ---
> arch/powerpc/lib/ppc_ksyms.c | 1 -
> 1 file changed, 1 deletion(-)
Acked-by: Michael Ellerman
cheers
> diff --git a/arch/powerpc/lib/ppc_ksyms.c b/arch/powerpc/lib/ppc_ksyms.c
> index c7f8e9586316..4b81fd96aa3e 100644
> --- a/arch/powerpc/lib/ppc_ksyms.c
> +++ b/arch/powerpc/lib/ppc_ksyms.c
> @@ -24,7 +24,6 @@ EXPORT_SYMBOL(csum_tcpudp_magic);
> #endif
>
> EXPORT_SYMBOL(__copy_tofrom_user);
> -EXPORT_SYMBOL(__clear_user);
> EXPORT_SYMBOL(copy_page);
>
> #ifdef CONFIG_PPC64
> --
> 2.26.2
Re: [PATCH] powerpc/xmon: Change printk() to pr_cont()
Christophe Leroy writes:
> Since some time now, printk() adds carriage return, leading to
> unusable xmon output:
>
> [ 54.288722] sysrq: Entering xmon
> [ 54.292209] Vector: 0 at [cace3d2c]
> [ 54.292274] pc:
> [ 54.292331] c0023650
...
> diff --git a/arch/powerpc/xmon/nonstdio.c b/arch/powerpc/xmon/nonstdio.c
> index 5c1a50912229..9b0d85bff021 100644
> --- a/arch/powerpc/xmon/nonstdio.c
> +++ b/arch/powerpc/xmon/nonstdio.c
> @@ -178,7 +178,7 @@ void xmon_printf(const char *format, ...)
>
> if (n && rc == 0) {
> /* No udbg hooks, fallback to printk() - dangerous */
> - printk("%s", xmon_outbuf);
> + pr_cont("%s", xmon_outbuf);
> }
Ah OK, in the case where there's no udbg backend. We basically always
have a udbg backend on 64-bit, via hvc console. Which explains why we
haven't noticed it.
Will pick up the patch.
cheers
Re: WARN_ON_ONCE
Dmitry Vyukov writes:
> On Thu, Dec 3, 2020 at 10:19 AM Dmitry Vyukov wrote:
>> On Thu, Dec 3, 2020 at 10:10 AM Alexey Kardashevskiy wrote:
>> >
>> > Hi!
>> >
>> > Syzkaller triggered WARN_ON_ONCE at
>> >
>> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/tracepoint.c?h=v5.10-rc6#n266
>> >
>> >
>> > ===
>> > static int tracepoint_add_func(struct tracepoint *tp,
>> >struct tracepoint_func *func, int prio)
>> > {
>> > struct tracepoint_func *old, *tp_funcs;
>> > int ret;
>> >
>> > if (tp->regfunc && !static_key_enabled(&tp->key)) {
>> > ret = tp->regfunc();
>> > if (ret < 0)
>> > return ret;
>> > }
>> >
>> > tp_funcs = rcu_dereference_protected(tp->funcs,
>> > lockdep_is_held(&tracepoints_mutex));
>> > old = func_add(&tp_funcs, func, prio);
>> > if (IS_ERR(old)) {
>> > WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
>> > return PTR_ERR(old);
>> > }
>> >
>> > ===
>> >
>> > What is the common approach here? Syzkaller reacts on this as if it was
>> > a bug but WARN_ON_ONCE here seems intentional. Do we still push for
>> > removing such warnings?
AFAICS it is a bug if that fires.
See the commit that added it:
d66a270be331 ("tracepoint: Do not warn on ENOMEM")
Which says:
Tracepoint should only warn when a kernel API user does not respect the
required preconditions (e.g. same tracepoint enabled twice, or called
to remove a tracepoint that does not exist).
Silence warning in out-of-memory conditions, given that the error is
returned to the caller.
So if you're seeing it then you've someone caused it to return something
other than ENOMEM, and that is a bug.
cheers
Re: [PATCH] powerpc/mm: Don't see NULL pointer dereference as a KUAP fault
Christophe Leroy writes:
> Sometimes, NULL pointer dereferences are expected. Even when they
> are accidental they are unlikely an exploit attempt because the
> first page is never mapped.
The first page can be mapped if mmap_min_addr is 0.
Blocking all faults to the first page would potentially break any
program that does that.
Also if there is something mapped at 0 it's a good chance it is an
exploit attempt :)
cheers
> The exemple below shows what we get when invoking the "show task"
> sysrq handler, by writing 't' in /proc/sysrq-trigger
>
> [ 1117.202054] [ cut here ]
> [ 1117.202102] Bug: fault blocked by AP register !
> [ 1117.202261] WARNING: CPU: 0 PID: 377 at
> arch/powerpc/include/asm/nohash/32/kup-8xx.h:66 do_page_fault+0x4a8/0x5ec
> [ 1117.202310] Modules linked in:
> [ 1117.202428] CPU: 0 PID: 377 Comm: sh Tainted: GW
> 5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty #4175
> [ 1117.202499] NIP: c0012048 LR: c0012048 CTR:
> [ 1117.202573] REGS: cacdbb88 TRAP: 0700 Tainted: GW
> (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
> [ 1117.202625] MSR: 00021032 CR: 2408 XER: 2000
> [ 1117.202899]
> [ 1117.202899] GPR00: c0012048 cacdbc40 c2929290 0023 c092e554 0001
> c09865e8 c092e640
> [ 1117.202899] GPR08: 1032 00014efc 28082224 100d166a
> 100a0920
> [ 1117.202899] GPR16: 100cac0c 100b 1080c3fc 1080d685 100d 100d
> 100a0900
> [ 1117.202899] GPR24: 100d c07892ec c0921510 c21f4440 005c
> c000 cacdbc80
> [ 1117.204362] NIP [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204461] LR [c0012048] do_page_fault+0x4a8/0x5ec
> [ 1117.204509] Call Trace:
> [ 1117.204609] [cacdbc40] [c0012048] do_page_fault+0x4a8/0x5ec (unreliable)
> [ 1117.204771] [cacdbc70] [c00112f0] handle_page_fault+0x8/0x34
> [ 1117.204911] --- interrupt: 301 at copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.204979] NIP: c010dbec LR: c010dbac CTR: 0001
> [ 1117.205053] REGS: cacdbc80 TRAP: 0301 Tainted: GW
> (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
> [ 1117.205104] MSR: 9032 CR: 28082224 XER:
> [ 1117.205416] DAR: 005c DSISR: c000
> [ 1117.205416] GPR00: c0045948 cacdbd38 c2929290 0001 0017 0017
> 0027 000f
> [ 1117.205416] GPR08: c09926ec 3000 24082224
> [ 1117.206106] NIP [c010dbec] copy_from_kernel_nofault+0x70/0x1c0
> [ 1117.206202] LR [c010dbac] copy_from_kernel_nofault+0x30/0x1c0
> [ 1117.206258] --- interrupt: 301
> [ 1117.206372] [cacdbd38] [c004bbb0] kthread_probe_data+0x44/0x70 (unreliable)
> [ 1117.206561] [cacdbd58] [c0045948] print_worker_info+0xe0/0x194
> [ 1117.206717] [cacdbdb8] [c00548ac] sched_show_task+0x134/0x168
> [ 1117.206851] [cacdbdd8] [c005a268] show_state_filter+0x70/0x100
> [ 1117.206989] [cacdbe08] [c039baa0] sysrq_handle_showstate+0x14/0x24
> [ 1117.207122] [cacdbe18] [c039bf18] __handle_sysrq+0xac/0x1d0
> [ 1117.207257] [cacdbe48] [c039c0c0] write_sysrq_trigger+0x4c/0x74
> [ 1117.207407] [cacdbe68] [c01fba48] proc_reg_write+0xb4/0x114
> [ 1117.207550] [cacdbe88] [c0179968] vfs_write+0x12c/0x478
> [ 1117.207686] [cacdbf08] [c0179e60] ksys_write+0x78/0x128
> [ 1117.207826] [cacdbf38] [c00110d0] ret_from_syscall+0x0/0x34
> [ 1117.207938] --- interrupt: c01 at 0xfd4e784
> [ 1117.208008] NIP: 0fd4e784 LR: 0fe0f244 CTR: 10048d38
> [ 1117.208083] REGS: cacdbf48 TRAP: 0c01 Tainted: GW
> (5.10.0-rc5-s3k-dev-01340-g83f53be2de31-dirty)
> [ 1117.208134] MSR: d032 CR: 4400 XER:
> [ 1117.208470]
> [ 1117.208470] GPR00: 0004 7fc34090 77bfb4e0 0001 1080fa40 0002
> 740f fefefeff
> [ 1117.208470] GPR08: 7f7f7f7f 10048d38 1080c414 7fc343c0
> [ 1117.209104] NIP [0fd4e784] 0xfd4e784
> [ 1117.209180] LR [0fe0f244] 0xfe0f244
> [ 1117.209236] --- interrupt: c01
> [ 1117.209274] Instruction dump:
> [ 1117.209353] 714a4000 418200f0 73ca0001 40820084 73ca0032 408200f8 73c90040
> 4082ff60
> [ 1117.209727] 0fe0 3c60c082 386399f4 48013b65 <0fe0> 80010034
> 386b 7c0803a6
> [ 1117.210102] ---[ end trace 1927c0323393af3e ]---
>
> So, avoid the big KUAP warning by bailing out of bad_kernel_fault()
> before calling bad_kuap_fault() when address references the first
> page.
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/mm/fault.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 0add963a849b..be2b4318206f 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -198,6 +198,10 @@ static bool bad_kernel_fault(struct pt_regs *regs,
> unsigned long error_code,
> {
> int is_exec = TRAP(regs) == 0x400;
>
> + // Kernel fault on first page is likely a NULL pointer dereference
> + if (address < PAGE_SIZE)
> + return true;
> +
> /* NX faults set DSISR_PROTFAULT on the 8xx, DSI
Re: [PATCH] EDAC, mv64x60: Fix error return code in mv64x60_pci_err_probe()
Borislav Petkov writes:
> On Tue, Nov 24, 2020 at 02:30:09PM +0800, Wang ShaoBo wrote:
>> Fix to return -ENODEV error code when edac_pci_add_device() failed instaed
>> of 0 in mv64x60_pci_err_probe(), as done elsewhere in this function.
>>
>> Fixes: 4f4aeeabc061 ("drivers-edac: add marvell mv64x60 driver")
>> Signed-off-by: Wang ShaoBo
>> ---
>> drivers/edac/mv64x60_edac.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/edac/mv64x60_edac.c b/drivers/edac/mv64x60_edac.c
>> index 3c68bb525d5d..456b9ca1fe8d 100644
>> --- a/drivers/edac/mv64x60_edac.c
>> +++ b/drivers/edac/mv64x60_edac.c
>> @@ -168,6 +168,7 @@ static int mv64x60_pci_err_probe(struct platform_device
>> *pdev)
>>
>> if (edac_pci_add_device(pci, pdata->edac_idx) > 0) {
>> edac_dbg(3, "failed edac_pci_add_device()\n");
>> +res = -ENODEV;
>> goto err;
>> }
>
> That driver depends on MV64X60 and I don't see anything in the tree
> enabling it and I can't select it AFAICT:
>
> config MV64X60
> bool
> select PPC_INDIRECT_PCI
> select CHECK_CACHE_COHERENCY
It was selected by PPC_C2K, but that was dropped in:
92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
> PPC folks, what do we do here?
>
> If not used anymore, I'd love to have one less EDAC driver.
It's dead code, so drop it.
I can send a patch if no one else wants to.
cheers
Re: [PATCH v2 02/24] exec: Simplify unshare_files
Arnd Bergmann writes: ... > > If there are no objections, I can also send a patch to remove > CONFIG_PPC_CELL_NATIVE, PPC_IBM_CELL_BLADE and > everything that depends on those symbols, leaving only the > bits needed by ps3 in the arch/powerpc/platforms/cell directory. I'm not sure I'd merge it. The only way I am able to (easily) test Cell code is by using one of those blades, a QS22 to be precise. So if the blade support is removed then the rest of the Cell code is likely to bitrot quickly. Which may be the goal. I'd be more inclined to support removal of the core dump code. That seems highly unlikely to be in active use, I don't have the impression there are many folks doing active development on Cell. cheers
Re: [PATCH 5/5] powerpc/configs: drop unused BACKLIGHT_GENERIC option
Andrey Zhizhikin writes:
> Commit 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused") removed geenric_bl driver from the tree, together with
> corresponding config option.
>
> Remove BACKLIGHT_GENERIC config item from generic-64bit_defconfig.
^
powernv_defconfig
> Fixes: 7ecdea4a0226 ("backlight: generic_bl: Remove this driver as it is
> unused")
> Cc: Sam Ravnborg
> Signed-off-by: Andrey Zhizhikin
> ---
> arch/powerpc/configs/powernv_defconfig | 1 -
> 1 file changed, 1 deletion(-)
Acked-by: Michael Ellerman
cheers
> diff --git a/arch/powerpc/configs/powernv_defconfig
> b/arch/powerpc/configs/powernv_defconfig
> index cf30fc24413b..60a30fffeda0 100644
> --- a/arch/powerpc/configs/powernv_defconfig
> +++ b/arch/powerpc/configs/powernv_defconfig
> @@ -208,7 +208,6 @@ CONFIG_FB_MATROX_G=y
> CONFIG_FB_RADEON=m
> CONFIG_FB_IBM_GXT4500=m
> CONFIG_LCD_PLATFORM=m
> -CONFIG_BACKLIGHT_GENERIC=m
> # CONFIG_VGA_CONSOLE is not set
> CONFIG_LOGO=y
> CONFIG_HID_A4TECH=m
> --
> 2.17.1
Re: [PATCH 2/3] powerpc/pseries/hotplug-cpu: fix memleak in dlpar_cpu_add_by_count
Qinglang Miao writes:
> kfree(cpu_drcs) should be called when it fails to perform
> of_find_node_by_path("/cpus") in dlpar_cpu_add_by_count,
> otherwise there would be a memleak.
>
> In fact, the patch a0ff72f9f5a7 ought to remove kfree in
> find_dlpar_cpus_to_add rather than dlpar_cpu_add_by_count.
> I guess there might be a mistake when apply that one.
>
> Fixes: a0ff72f9f5a7 ("powerpc/pseries/hotplug-cpu: Remove double free in
> error path")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 1 +
> 1 file changed, 1 insertion(+)
This is already fixed in my next by:
a40fdaf1420d ("Revert "powerpc/pseries/hotplug-cpu: Remove double free in
error path"")
cheers
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index f2837e33b..4bb1c9f2b 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -743,6 +743,7 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> parent = of_find_node_by_path("/cpus");
> if (!parent) {
> pr_warn("Could not find CPU root node in device tree\n");
> + kfree(cpu_drcs);
> return -1;
> }
>
> --
> 2.23.0
[GIT PULL] Please pull powerpc/linux.git powerpc-5.10-4 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull some more powerpc fixes for 5.10. Note this includes a merge of the powerpc-cve-2020-4788 tag, which you already have, so that I could fix a build break it introduced. That merge should be a nop from your POV. cheers The following changes since commit da631f7fd623b6c180c8d93a93040d1e0d61291f: Linux 5.10-rc2 (2020-11-01 14:43:51 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.10-4 for you to fetch changes up to b6b79dd53082db11070b4368d85dd6699ff0b063: powerpc/64s: Fix allnoconfig build since uaccess flush (2020-11-23 21:16:42 +1100) - -- powerpc fixes for 5.10 #4 A regression fix for a boot failure on some 32-bit machines. A fix for host crashes in the KVM system reset handling. A fix for a possible oops in the KVM XIVE interrupt handling on Power9. A fix for host crashes triggerable via the KVM emulated MMIO handling when running HPT guests. A couple of small build fixes. Thanks to: Andreas Schwab, Cédric Le Goater, Christophe Leroy, Erhard Furtner, Greg Kurz, Greg Kurz, Németh Márton, Nicholas Piggin, Nick Desaulniers, Serge Belyshev, Stephen Rothwell. - -- Christophe Leroy (1): powerpc/32s: Use relocation offset when setting early hash table Cédric Le Goater (1): KVM: PPC: Book3S HV: XIVE: Fix possible oops when accessing ESB page Michael Ellerman (2): powerpc: Drop -me200 addition to build flags Merge tag 'powerpc-cve-2020-4788' into fixes Nicholas Piggin (2): powerpc/64s: Fix KVM system reset handling when CONFIG_PPC_PSERIES=y powerpc/64s/exception: KVM Fix for host DSI being taken in HPT guest MMU context Stephen Rothwell (1): powerpc/64s: Fix allnoconfig build since uaccess flush arch/powerpc/Makefile | 1 - arch/powerpc/include/asm/book3s/64/kup-radix.h | 2 ++ arch/powerpc/kernel/exceptions-64s.S | 13 +++-- arch/powerpc/kernel/head_book3s_32.S | 3 ++- arch/powerpc/kvm/book3s_xive_native.c | 7 +++ 5 files changed, 18 insertions(+), 8 deletions(-) -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl/A8B4ACgkQUevqPMjh pYCUdQ/9HN2ikGl+dT5h3CoAVZoGsyl6/KQm6t+tVjHHxDWcuH/wOmmpvqRET5th 7uGOJrKEPaWDo3KwmM/Q2Srf74Qtb23n4D62Hi4dTBGoVix1930BIrz/VaQq416T WwvrZIwbOSOvklbERq/ta4YeXN9fHquAX0dgxQEWPgLugoXCJhKndvAoy+l+0ZLa F3uOFnqt1IKaQA7wM7I+BbgOlP6rF+VhNPMZmUEvNDsVa6HUhv6/R46c7Un4jKyQ O8hTn/yz/Sc7kB06LoF9PiHlwtZVuDvwIi+6h5W1LcLCWGIBkEhJkNZ1K6Qwiu7H YIFvCTLovliLSOYIRjRS+s1a0hSjRUdOcrb/VukzRNP/JFpbzKid8gHkVdG8yEN8 HIXT6W9/YOACr+rviuYJAuA+hk4ll8SHdgbFnr7QGLJKdy9SCUHSWrkgoBHXKig5 eV/bRE0H5WauyqPcct1xP781UKf1zmcNiouvDXmRBoAJalRSVFB5HxpN+GKPQxwu la/lv/eAujuydJYxlgCHu8pNbn/DhPsIPpbNnXLNOYxiWR8LXESkt4I7dxPJQxvr pkWuR+T1FAXzF6tor+iK8anpmAmXKrWFQNSC2cCnqBdGtORdARztjHhVWgOCQLiR H0mN8abC+b7h6LVsRsDieZt5u0+o+G69FvNLxaPQymvnDaQtbQI= =7BPy -END PGP SIGNATURE-
Re: [PATCH v3 2/2] powerpc/pseries: pass MSI affinity to irq_create_mapping()
Marc Zyngier writes:
> On 2020-11-25 16:24, Laurent Vivier wrote:
>> On 25/11/2020 17:05, Denis Kirjanov wrote:
>>> On 11/25/20, Laurent Vivier wrote:
With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ
affinity")
this is broken on pseries.
>>>
>>> Please add "Fixes" tag.
>>
>> In fact, the code in commit 0d9f0a52c8b9f is correct.
>>
>> The problem is with MSI/X irq affinity and pseries. So this patch
>> fixes more than virtio_scsi. I put this information because this
>> commit allows to clearly show the problem. Perhaps I should remove
>> this line in fact?
>
> This patch does not fix virtio_scsi at all, which as you noticed, is
> correct. It really fixes the PPC MSI setup, which is starting to show
> its age. So getting rid of the reference seems like the right thing to
> do.
It's still useful to refer to that commit if the code worked prior to
that commit. But you should make it clearer that 0d9f0a52c8b9f wasn't in
error, it just exposed an existing shortcoming of the arch code.
cheers
Re: [PATCH v3 2/2] powerpc/pseries: pass MSI affinity to irq_create_mapping()
Laurent Vivier writes:
> With virtio multiqueue, normally each queue IRQ is mapped to a CPU.
>
> But since commit 0d9f0a52c8b9f ("virtio_scsi: use virtio IRQ affinity")
> this is broken on pseries.
>
> The affinity is correctly computed in msi_desc but this is not applied
> to the system IRQs.
>
> It appears the affinity is correctly passed to rtas_setup_msi_irqs() but
> lost at this point and never passed to irq_domain_alloc_descs()
> (see commit 06ee6d571f0e ("genirq: Add affinity hint to irq allocation"))
> because irq_create_mapping() doesn't take an affinity parameter.
>
> As the previous patch has added the affinity parameter to
> irq_create_mapping() we can forward the affinity from rtas_setup_msi_irqs()
> to irq_domain_alloc_descs().
>
> With this change, the virtqueues are correctly dispatched between the CPUs
> on pseries.
>
> BugId: https://bugzilla.redhat.com/show_bug.cgi?id=1702939
> Signed-off-by: Laurent Vivier
> Reviewed-by: Greg Kurz
> ---
> arch/powerpc/platforms/pseries/msi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Michael Ellerman
cheers
> diff --git a/arch/powerpc/platforms/pseries/msi.c
> b/arch/powerpc/platforms/pseries/msi.c
> index 133f6adcb39c..b3ac2455faad 100644
> --- a/arch/powerpc/platforms/pseries/msi.c
> +++ b/arch/powerpc/platforms/pseries/msi.c
> @@ -458,7 +458,8 @@ static int rtas_setup_msi_irqs(struct pci_dev *pdev, int
> nvec_in, int type)
> return hwirq;
> }
>
> - virq = irq_create_mapping(NULL, hwirq);
> + virq = irq_create_mapping_affinity(NULL, hwirq,
> +entry->affinity);
>
> if (!virq) {
> pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
> --
> 2.28.0
Re: [PATCH] powerpc/mm: Fix comparing pointer to 0 warning
On Tue, 10 Nov 2020 10:56:01 +0800, xiakaixu1...@gmail.com wrote: > Fixes coccicheck warning: > > ./arch/powerpc/mm/pgtable_32.c:87:11-12: WARNING comparing pointer to 0 > > Avoid pointer type value compared to 0. Applied to powerpc/next. [1/1] powerpc/mm: Fix comparing pointer to 0 warning https://git.kernel.org/powerpc/c/b84bf098fcc49ed6bf4b0a8bed52e9df0e8f1de7 cheers
Re: [PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
On Tue, 10 Nov 2020 19:19:30 +0800, xiakaixu1...@gmail.com wrote: > Fix coccicheck warning: > > ./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned > expression compared with zero: win < 0 > ./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned > expression compared with zero: win < 0 Applied to powerpc/next. [1/1] powerpc/powernv/sriov: fix unsigned int win compared to less than zero https://git.kernel.org/powerpc/c/027717a45ca251a7ba67a63db359994836962cd2 cheers
Re: [PATCH v2 0/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
On Wed, 11 Nov 2020 15:53:14 +0100, David Hildenbrand wrote: > Based on latest linux/master > > powernv/memtrace is the only in-kernel user that rips out random memory > it never added (doesn't own) in order to allocate memory without a > linear mapping. Let's stop abusing memory hot(un)plug infrastructure for > that - use alloc_contig_pages() for allocating memory and remove the > linear mapping manually. > > [...] Applied to powerpc/next. [1/8] powerpc/powernv/memtrace: Don't leak kernel memory to user space https://git.kernel.org/powerpc/c/c74cf7a3d59a21b290fe0468f5b470d0b8ee37df [2/8] powerpc/powernv/memtrace: Fix crashing the kernel when enabling concurrently https://git.kernel.org/powerpc/c/d6718941a2767fb383e105d257d2105fe4f15f0e [3/8] powerpc/mm: factor out creating/removing linear mapping https://git.kernel.org/powerpc/c/4abb1e5b63ac3281275315fc6b0cde0b9c2e2e42 [4/8] powerpc/mm: protect linear mapping modifications by a mutex https://git.kernel.org/powerpc/c/e5b2af044f31bf18defa557a8cd11c23caefa34c [5/8] powerpc/mm: print warning in arch_remove_linear_mapping() https://git.kernel.org/powerpc/c/1f73ad3e8d755dbec52fcec98618a7ce4de12af2 [6/8] powerpc/book3s64/hash: Drop WARN_ON in hash__remove_section_mapping() https://git.kernel.org/powerpc/c/d8bd9a121c2f2bc8b36da930dc91b69fd2a705e2 [7/8] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory() https://git.kernel.org/powerpc/c/ca2c36cae9d48b180ea51259e35ab3d95d327df2 [8/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations https://git.kernel.org/powerpc/c/0bd4b96d99108b7ea9bac0573957483be7781d70 cheers
Re: [PATCH] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S
On Wed, 4 Nov 2020 18:59:10 +0800, Youling Tang wrote: > Use the common INIT_DATA_SECTION rule for the linker script in an effort > to regularize the linker script. Applied to powerpc/next. [1/1] powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S https://git.kernel.org/powerpc/c/fdcfeaba38e5b183045f5b079af94f97658eabe6 cheers
Re: [PATCHv2] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic
On Fri, 23 Oct 2020 10:45:39 +0800, Po-Hsu Lin wrote: > The eeh-basic test got its own 60 seconds timeout (defined in commit > 414f50434aa2 "selftests/eeh: Bump EEH wait time to 60s") per breakable > device. > > And we have discovered that the number of breakable devices varies > on different hardware. The device recovery time ranges from 0 to 35 > seconds. In our test pool it will take about 30 seconds to run on a > Power8 system that with 5 breakable devices, 60 seconds to run on a > Power9 system that with 4 breakable devices. > > [...] Applied to powerpc/next. [1/1] selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic https://git.kernel.org/powerpc/c/f5eca0b279117f25020112a2f65ec9c3ea25f3ac cheers
Re: [PATCH] powerpc: sysdev: add missing iounmap() on error in mpic_msgr_probe()
On Wed, 28 Oct 2020 17:15:51 +0800, Qinglang Miao wrote: > I noticed that iounmap() of msgr_block_addr before return from > mpic_msgr_probe() in the error handling case is missing. So use > devm_ioremap() instead of just ioremap() when remapping the message > register block, so the mapping will be automatically released on > probe failure. Applied to powerpc/next. [1/1] powerpc: sysdev: add missing iounmap() on error in mpic_msgr_probe() https://git.kernel.org/powerpc/c/ffa1797040c5da391859a9556be7b735acbe1242 cheers
Re: [PATCH v1 0/4] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations
On Thu, 29 Oct 2020 17:27:14 +0100, David Hildenbrand wrote: > powernv/memtrace is the only in-kernel user that rips out random memory > it never added (doesn't own) in order to allocate memory without a > linear mapping. Let's stop abusing memory hot(un)plug infrastructure for > that - use alloc_contig_pages() for allocating memory and remove the > linear mapping manually. > > The original idea was discussed in: > https://lkml.kernel.org/r/48340e96-7e6b-736f-9e23-d3111b915...@redhat.com > > [...] Applied to powerpc/next. [1/4] powerpc/mm: factor out creating/removing linear mapping https://git.kernel.org/powerpc/c/4abb1e5b63ac3281275315fc6b0cde0b9c2e2e42 [2/4] powerpc/mm: print warning in arch_remove_linear_mapping() https://git.kernel.org/powerpc/c/1f73ad3e8d755dbec52fcec98618a7ce4de12af2 [3/4] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory() https://git.kernel.org/powerpc/c/ca2c36cae9d48b180ea51259e35ab3d95d327df2 [4/4] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations https://git.kernel.org/powerpc/c/0bd4b96d99108b7ea9bac0573957483be7781d70 cheers
Re: [PATCH] powerpc/bitops: Fix possible undefined behaviour with fls() and fls64()
On Thu, 22 Oct 2020 14:05:46 + (UTC), Christophe Leroy wrote: > fls() and fls64() are using __builtin_ctz() and _builtin_ctzll(). > On powerpc, those builtins trivially use ctlzw and ctlzd power > instructions. > > Allthough those instructions provide the expected result with > input argument 0, __builtin_ctz() and __builtin_ctzll() are > documented as undefined for value 0. > > [...] Applied to powerpc/next. [1/1] powerpc/bitops: Fix possible undefined behaviour with fls() and fls64() https://git.kernel.org/powerpc/c/1891ef21d92c4801ea082ee8ed478e304ddc6749 cheers
Re: [PATCH v2 1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI
On Sun, 8 Nov 2020 16:57:35 + (UTC), Christophe Leroy wrote: > In head_64.S, we have two places using RFI to return to > kernel. Use RFI_TO_KERNEL instead. > > They are the two only places using RFI on book3s/64, so > the RFI macro can go away. Applied to powerpc/next. [1/3] powerpc/64s: Replace RFI by RFI_TO_KERNEL and remove RFI https://git.kernel.org/powerpc/c/879add7720172ffd2986c44587510fabb7af52f5 [2/3] powerpc: Replace RFI by rfi on book3s/32 and booke https://git.kernel.org/powerpc/c/120c0518ec321f33cdc4670059fb76e96ceb56eb [3/3] powerpc: Remove RFI macro https://git.kernel.org/powerpc/c/62182e6c0faf75117f8d1719c118bb5fc8574012 cheers
Re: [PATCH v13 0/8] powerpc: switch VDSO to C implementation
On Tue, 3 Nov 2020 18:07:11 + (UTC), Christophe Leroy wrote: > This is a series to switch powerpc VDSO to generic C implementation. > > Changes in v13: > - Reorganised headers to avoid the need for a fake 32 bits config for > building VDSO32 on PPC64 > - Rebased after the removal of powerpc 601 > - Using DOTSYM() macro to call functions directly without using OPD > - Explicitely dropped .opd and .got1 sections which are now unused > > [...] Patch 1 applied to powerpc/next. [1/8] powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32 https://git.kernel.org/powerpc/c/78665179e569c7e1fe102fb6c21d0f5b6951f084 cheers
Re: [PATCH] powerpc: avoid broken GCC __attribute__((optimize))
On Wed, 28 Oct 2020 09:04:33 +0100, Ard Biesheuvel wrote:
> Commit 7053f80d9696 ("powerpc/64: Prevent stack protection in early boot")
> introduced a couple of uses of __attribute__((optimize)) with function
> scope, to disable the stack protector in some early boot code.
>
> Unfortunately, and this is documented in the GCC man pages [0], overriding
> function attributes for optimization is broken, and is only supported for
> debug scenarios, not for production: the problem appears to be that
> setting GCC -f flags using this method will cause it to forget about some
> or all other optimization settings that have been applied.
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Avoid broken GCC __attribute__((optimize))
https://git.kernel.org/powerpc/c/a7223f5bfcaeade4a86d35263493bcda6c940891
cheers
Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
Namhyung Kim writes:
> Hello,
>
> On Mon, Nov 23, 2020 at 8:00 PM Michael Ellerman wrote:
>>
>> Namhyung Kim writes:
>> > Hi Peter and Kan,
>> >
>> > (Adding PPC folks)
>> >
>> > On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim wrote:
>> >>
>> >> Hello,
>> >>
>> >> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan
>> >> wrote:
>> >> >
>> >> >
>> >> >
>> >> > On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
>> >> > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
>> >> > >
>> >> > >> - When the large PEBS was introduced (9c964efa4330), the
>> >> > >> sched_task() should
>> >> > >> be invoked to flush the PEBS buffer in each context switch. However,
>> >> > >> The
>> >> > >> perf_sched_events in account_event() is not updated accordingly. The
>> >> > >> perf_event_task_sched_* never be invoked for a pure per-CPU context.
>> >> > >> Only
>> >> > >> per-task event works.
>> >> > >> At that time, the perf_pmu_sched_task() is outside of
>> >> > >> perf_event_context_sched_in/out. It means that perf has to double
>> >> > >> perf_pmu_disable() for per-task event.
>> >> > >
>> >> > >> - The patch 1 tries to fix broken per-CPU events. The CPU context
>> >> > >> cannot be
>> >> > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in
>> >> > >> the
>> >> > >> sched_cb_list. Yes, the code is very similar to the original codes,
>> >> > >> but it
>> >> > >> is actually the new code for per-CPU events. The optimization for
>> >> > >> per-task
>> >> > >> events is still kept.
>> >> > >>For the case, which has both a CPU context and a task context,
>> >> > >> yes, the
>> >> > >> __perf_pmu_sched_task() in this patch is not invoked. Because the
>> >> > >> sched_task() only need to be invoked once in a context switch. The
>> >> > >> sched_task() will be eventually invoked in the task context.
>> >> > >
>> >> > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
>> >> > > only set that for large pebs. Are you sure the other users (Intel LBR
>> >> > > and PowerPC BHRB) don't need it?
>> >> >
>> >> > I didn't set it for LBR, because the perf_sched_events is always enabled
>> >> > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
>> >> > for LBR.
>> >> >
>> >> > if (has_branch_stack(event))
>> >> > inc = true;
>> >> >
>> >> > >
>> >> > > If they indeed do not require the pmu::sched_task() callback for CPU
>> >> > > events, then I still think the whole perf_sched_cb_{inc,dec}()
>> >> > > interface
>> >> >
>> >> > No, LBR requires the pmu::sched_task() callback for CPU events.
>> >> >
>> >> > Now, The LBR registers have to be reset in sched in even for CPU events.
>> >> >
>> >> > To fix the shorter LBR callstack issue for CPU events, we also need to
>> >> > save/restore LBRs in pmu::sched_task().
>> >> > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.li...@linux.intel.com/
>> >> >
>> >> > > is confusing at best.
>> >> > >
>> >> > > Can't we do something like this instead?
>> >> > >
>> >> > I think the below patch may have two issues.
>> >> > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well)
>> >> > now.
>> >> > - We may disable the large PEBS later if not all PEBS events support
>> >> > large PEBS. The PMU need a way to notify the generic code to decrease
>> >> > the nr_sched_task.
>> >>
>> >> Any updates on this? I've reviewed and tested Kan's patches
>> >> and they all look good.
>> >>
>> >> Maybe we can talk to PPC folks to confirm the BHRB case?
>> >
>> > Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
>> > for PowerPC too. But it'd be nice if ppc folks can confirm the change.
>>
>> Sorry I've read the whole thread, but I'm still not entirely sure I
>> understand the question.
>
> Thanks for your time and sorry about not being clear enough.
>
> We found per-cpu events are not calling pmu::sched_task()
> on context switches. So PERF_ATTACH_SCHED_CB was
> added to indicate the core logic that it needs to invoke the
> callback.
OK. TBH I've never thought of using branch stack with a per-cpu event,
but I guess you can do it.
I think the same logic applies as LBR, we need to read the BHRB entries
in the context of the task that they were recorded for.
> The patch 3/3 added the flag to PPC (for BHRB) with other
> changes (I think it should be split like in the patch 2/3) and
> want to get ACKs from the PPC folks.
If you post a new version with Maddy's comments addressed then he or I
can ack it.
cheers
Re: linux-next: build failure in Linus' tree
Daniel Axtens writes: > Thanks sfr and mpe. > >> Applied to powerpc/fixes. >> >> [1/1] powerpc/64s: Fix allnoconfig build since uaccess flush >> >> https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063 > > We also needed a similar fix for stable, which has also been applied. > > I guess I should build some sort of build process that tests a whole > range of configs. I did test a few but clearly not enough. Is there a > known list that I should be using? Something from kisskb? It's basically unsolvable in general. I guess allnoconfig is a good one to build, although by default that gets you a 32-bit config. I'll send a patch to add ppc64le_allnoconfig. cheers
Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
Oleg Nesterov writes: > Christophe, et al, > > So what? > > Are you going to push your change or should I re-send 1-2 without > whitespace cleanups? I'll take your 1 & 2 and fixup the whitespace issues when applying. cheers > On 11/19, Oleg Nesterov wrote: >> >> On 11/19, Christophe Leroy wrote: >> > >> > I think the following should work, and not require the first patch (compile >> > tested only). >> > >> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c >> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c >> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const >> > struct user_regset *regset, >> >BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) != >> > offsetof(struct pt_regs, msr) + sizeof(long)); >> > >> > +#ifdef CONFIG_PPC64 >> > + membuf_write(&to, &target->thread.regs->orig_gpr3, >> > + offsetof(struct pt_regs, softe) - offsetof(struct pt_regs, >> > orig_gpr3)); >> > + membuf_store(&to, 1UL); >> > + >> > + BUILD_BUG_ON(offsetof(struct pt_regs, trap) != >> > + offsetof(struct pt_regs, softe) + sizeof(long)); >> > + >> > + membuf_write(&to, &target->thread.regs->trap, >> > + sizeof(struct user_pt_regs) - offsetof(struct pt_regs, >> > trap)); >> > +#else >> >membuf_write(&to, &target->thread.regs->orig_gpr3, >> >sizeof(struct user_pt_regs) - >> >offsetof(struct pt_regs, orig_gpr3)); >> > +#endif >> >return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) - >> > sizeof(struct user_pt_regs)); >> > } >> >> Probably yes. >> >> This mirrors the previous patch I sent >> (https://lore.kernel.org/lkml/20190917143753.ga12...@redhat.com/) >> and this is exactly what I tried to avoid, we can make a simpler fix now. >> >> But let me repeat, I agree with any fix even if imp my version simplifies >> the code, just >> commit this change and lets forget this problem. >> >> Oleg.
Re: linux-next: build failure in Linus' tree
On Mon, 23 Nov 2020 18:40:16 +1100, Stephen Rothwell wrote: > After merging most of the trees, today's linux-next build (powerpc64 > allnoconfig) failed like this: > > In file included from arch/powerpc/include/asm/kup.h:18, > from arch/powerpc/include/asm/uaccess.h:9, > from include/linux/uaccess.h:11, > from include/linux/sched/task.h:11, > from include/linux/sched/signal.h:9, > from include/linux/rcuwait.h:6, > from include/linux/percpu-rwsem.h:7, > from include/linux/fs.h:33, > from include/linux/compat.h:17, > from arch/powerpc/kernel/asm-offsets.c:14: > arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition > has no type or storage class >66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key); > | ^~~~ > arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to > 'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int] > arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names > (without types) in function declaration > arch/powerpc/include/asm/book3s/64/kup-radix.h: In function > 'prevent_user_access': > arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit > declaration of function 'static_branch_unlikely' > [-Werror=implicit-function-declaration] > 180 | if (static_branch_unlikely(&uaccess_flush_key)) > | ^~ > arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error: > 'uaccess_flush_key' undeclared (first use in this function) > 180 | if (static_branch_unlikely(&uaccess_flush_key)) > | ^ > arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared > identifier is reported only once for each function it appears in > arch/powerpc/include/asm/book3s/64/kup-radix.h: In function > 'prevent_user_access_return': > arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error: > 'uaccess_flush_key' undeclared (first use in this function) > 189 | if (static_branch_unlikely(&uaccess_flush_key)) > | ^ > arch/powerpc/include/asm/book3s/64/kup-radix.h: In function > 'restore_user_access': > arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error: > 'uaccess_flush_key' undeclared (first use in this function) > 198 | if (static_branch_unlikely(&uaccess_flush_key) && flags == > AMR_KUAP_BLOCKED) > | ^ > > [...] Applied to powerpc/fixes. [1/1] powerpc/64s: Fix allnoconfig build since uaccess flush https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063 cheers
Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
Namhyung Kim writes:
> Hi Peter and Kan,
>
> (Adding PPC folks)
>
> On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim wrote:
>>
>> Hello,
>>
>> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan wrote:
>> >
>> >
>> >
>> > On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
>> > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
>> > >
>> > >> - When the large PEBS was introduced (9c964efa4330), the sched_task()
>> > >> should
>> > >> be invoked to flush the PEBS buffer in each context switch. However, The
>> > >> perf_sched_events in account_event() is not updated accordingly. The
>> > >> perf_event_task_sched_* never be invoked for a pure per-CPU context.
>> > >> Only
>> > >> per-task event works.
>> > >> At that time, the perf_pmu_sched_task() is outside of
>> > >> perf_event_context_sched_in/out. It means that perf has to double
>> > >> perf_pmu_disable() for per-task event.
>> > >
>> > >> - The patch 1 tries to fix broken per-CPU events. The CPU context
>> > >> cannot be
>> > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in the
>> > >> sched_cb_list. Yes, the code is very similar to the original codes, but
>> > >> it
>> > >> is actually the new code for per-CPU events. The optimization for
>> > >> per-task
>> > >> events is still kept.
>> > >>For the case, which has both a CPU context and a task context, yes,
>> > >> the
>> > >> __perf_pmu_sched_task() in this patch is not invoked. Because the
>> > >> sched_task() only need to be invoked once in a context switch. The
>> > >> sched_task() will be eventually invoked in the task context.
>> > >
>> > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
>> > > only set that for large pebs. Are you sure the other users (Intel LBR
>> > > and PowerPC BHRB) don't need it?
>> >
>> > I didn't set it for LBR, because the perf_sched_events is always enabled
>> > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
>> > for LBR.
>> >
>> > if (has_branch_stack(event))
>> > inc = true;
>> >
>> > >
>> > > If they indeed do not require the pmu::sched_task() callback for CPU
>> > > events, then I still think the whole perf_sched_cb_{inc,dec}() interface
>> >
>> > No, LBR requires the pmu::sched_task() callback for CPU events.
>> >
>> > Now, The LBR registers have to be reset in sched in even for CPU events.
>> >
>> > To fix the shorter LBR callstack issue for CPU events, we also need to
>> > save/restore LBRs in pmu::sched_task().
>> > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.li...@linux.intel.com/
>> >
>> > > is confusing at best.
>> > >
>> > > Can't we do something like this instead?
>> > >
>> > I think the below patch may have two issues.
>> > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well)
>> > now.
>> > - We may disable the large PEBS later if not all PEBS events support
>> > large PEBS. The PMU need a way to notify the generic code to decrease
>> > the nr_sched_task.
>>
>> Any updates on this? I've reviewed and tested Kan's patches
>> and they all look good.
>>
>> Maybe we can talk to PPC folks to confirm the BHRB case?
>
> Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
> for PowerPC too. But it'd be nice if ppc folks can confirm the change.
Sorry I've read the whole thread, but I'm still not entirely sure I
understand the question.
cheers
Re: [PATCH] selftests/seccomp: powerpc: Fix typo in macro variable name
Kees Cook writes:
> A typo sneaked into the powerpc selftest. Fix the name so it builds again.
>
> Fixes: 46138329faea ("selftests/seccomp: powerpc: Fix seccomp return value
> testing")
> Signed-off-by: Kees Cook
> ---
> tools/testing/selftests/seccomp/seccomp_bpf.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I hit that and thought I'd sent a patch for it, but seems I never
actually sent it.
So thanks. I assume Shuah will take it.
Acked-by: Michael Ellerman
cheers
> diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c
> b/tools/testing/selftests/seccomp/seccomp_bpf.c
> index 76c458055c54..26c72f2b61b1 100644
> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
> @@ -1758,10 +1758,10 @@ TEST_F(TRACE_poke, getpid_runs_normally)
>* and the code is stored as a positive value. \
>*/ \
> if (_result < 0) { \
> - SYSCALL_RET(_regs) = -result; \
> + SYSCALL_RET(_regs) = -_result; \
> (_regs).ccr |= 0x1000; \
> } else {\
> - SYSCALL_RET(_regs) = result;\
> + SYSCALL_RET(_regs) = _result; \
> (_regs).ccr &= ~0x1000; \
> } \
> } while (0)
> --
> 2.25.1
Re: [PATCH v2 7/8] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory()
David Hildenbrand writes: > On 17.11.20 16:51, Oscar Salvador wrote: >> On Wed, Nov 11, 2020 at 03:53:21PM +0100, David Hildenbrand wrote: >>> Let's revert what we did in case seomthing goes wrong and we return an >> "something" :-) > > Thanks! :) > > @Michael, I assume if I don't have to resend, this can be fixed up? Yep, I fixed it up. cheers
Re: [PATCH 2/3] Revert "lib: Revert use of fallthrough pseudo-keyword in lib/"
"Gustavo A. R. Silva" writes:
> On Tue, Nov 17, 2020 at 11:10:26AM -0800, Nick Desaulniers wrote:
>> On Mon, Nov 16, 2020 at 7:02 PM Nathan Chancellor
>> wrote:
>> >
>> > On Sun, Nov 15, 2020 at 08:35:31PM -0800, Nick Desaulniers wrote:
>> > > This reverts commit 6a9dc5fd6170 ("lib: Revert use of fallthrough
>> > > pseudo-keyword in lib/")
>>
>> Gustavo, whose tree did 6a9dc5fd6170 and df561f6688fe go up to
>
> Mine.
>
>> mainline in? I'm not sure whether you or MPE (ppc) or someone else
>> should pick it this series?
>
> I'm happy to take this series in my tree. I'm planing to send a
> pull-request for -rc5 with more related changes. So, I can include
> this in the same PR.
I doesn't really seem like rc5 material to me, but that's up to you.
I'd rather not take it in my tree because there's a lot of changes in
lib/ and that's not my area. I'm happy for the two powerpc patches to go
via your tree.
cheers
Re: [PATCH 3/3] powerpc: fix -Wimplicit-fallthrough
Nick Desaulniers writes: > The "fallthrough" pseudo-keyword was added as a portable way to denote > intentional fallthrough. Clang will still warn on cases where there is a > fallthrough to an immediate break. Add explicit breaks for those cases. > > Link: https://github.com/ClangBuiltLinux/linux/issues/236 > Signed-off-by: Nick Desaulniers > --- > arch/powerpc/kernel/prom_init.c | 1 + > arch/powerpc/kernel/uprobes.c | 1 + > arch/powerpc/perf/imc-pmu.c | 1 + > 3 files changed, 3 insertions(+) Acked-by: Michael Ellerman cheers
Re: [PATCH 1/3] powerpc: boot: include compiler_attributes.h
Nick Desaulniers writes: > The kernel uses `-include` to include include/linux/compiler_types.h > into all translation units (see scripts/Makefile.lib), which #includes > compiler_attributes.h. > > arch/powerpc/boot/ uses different compiler flags from the rest of the > kernel. As such, it doesn't contain the definitions from these headers, > and redefines a few that it needs. > > For the purpose of enabling -Wimplicit-fallthrough for ppc, include > compiler_types.h via `-include`. > > Link: https://github.com/ClangBuiltLinux/linux/issues/236 > Signed-off-by: Nick Desaulniers > --- > We could just `#include "include/linux/compiler_types.h"` in the few .c > sources used from lib/ (there are proper header guards in > compiler_types.h). > > It was also noted in 6a9dc5fd6170 that we could -D__KERNEL__ and > -include compiler_types.h like the main kernel does, though testing that > produces a whole sea of warnings to cleanup. This approach is minimally > invasive. > > arch/powerpc/boot/Makefile | 1 + > arch/powerpc/boot/decompress.c | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) Acked-by: Michael Ellerman cheers
Re: [PATCH] powerpc: Drop -me200 addition to build flags
On Mon, 16 Nov 2020 23:09:13 +1100, Michael Ellerman wrote: > Currently a build with CONFIG_E200=y will fail with: > > Error: invalid switch -me200 > Error: unrecognized option -me200 > > Upstream binutils has never supported an -me200 option. Presumably it > was supported at some point by either a fork or Freescale internal > binutils. > > [...] Applied to powerpc/fixes. [1/1] powerpc: Drop -me200 addition to build flags https://git.kernel.org/powerpc/c/e02152ba2810f7c88cb54e71cda096268dfa9241 cheers
Re: [PATCH 1/2] kbuild: Hoist '--orphan-handling' into Kconfig
Nathan Chancellor writes: > Currently, '--orphan-handling=warn' is spread out across four different > architectures in their respective Makefiles, which makes it a little > unruly to deal with in case it needs to be disabled for a specific > linker version (in this case, ld.lld 10.0.1). > > To make it easier to control this, hoist this warning into Kconfig and > the main Makefile so that disabling it is simpler, as the warning will > only be enabled in a couple places (main Makefile and a couple of > compressed boot folders that blow away LDFLAGS_vmlinx) and making it > conditional is easier due to Kconfig syntax. One small additional > benefit of this is saving a call to ld-option on incremental builds > because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN. > > To keep the list of supported architectures the same, introduce > CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to > gain this automatically after all of the sections are specified and size > asserted. A special thanks to Kees Cook for the help text on this > config. > > Link: https://github.com/ClangBuiltLinux/linux/issues/1187 > Signed-off-by: Nathan Chancellor > --- > Makefile | 6 ++ > arch/Kconfig | 9 + > arch/arm/Kconfig | 1 + > arch/arm/Makefile | 4 > arch/arm/boot/compressed/Makefile | 4 +++- > arch/arm64/Kconfig| 1 + > arch/arm64/Makefile | 4 > arch/powerpc/Kconfig | 1 + > arch/powerpc/Makefile | 1 - Acked-by: Michael Ellerman (powerpc) > arch/x86/Kconfig | 1 + > arch/x86/Makefile | 3 --- > arch/x86/boot/compressed/Makefile | 4 +++- > init/Kconfig | 3 +++ > 13 files changed, 28 insertions(+), 14 deletions(-) > > diff --git a/Makefile b/Makefile > index 008aba5f1a20..c443afd61886 100644 > --- a/Makefile > +++ b/Makefile > @@ -984,6 +984,12 @@ ifeq ($(CONFIG_RELR),y) > LDFLAGS_vmlinux += --pack-dyn-relocs=relr > endif > > +# We never want expected sections to be placed heuristically by the > +# linker. All sections should be explicitly named in the linker script. > +ifeq ($(CONFIG_LD_ORPHAN_WARN),y) > +LDFLAGS_vmlinux += --orphan-handling=warn > +endif This is a nit, but you can use ifdef with bool CONFIG symbols in Makefiles, which reads a bit nicer, eg: ifdef CONFIG_LD_ORPHAN_WARN LDFLAGS_vmlinux += --orphan-handling=warn endif cheers
Re: [PATCH] powerpc/powernv/sriov: fix unsigned int win compared to less than zero
Andrew Donnellan writes:
> On 10/11/20 10:19 pm, xiakaixu1...@gmail.com wrote:
>> From: Kaixu Xia
>>
>> Fix coccicheck warning:
>>
>> ./arch/powerpc/platforms/powernv/pci-sriov.c:443:7-10: WARNING: Unsigned
>> expression compared with zero: win < 0
>> ./arch/powerpc/platforms/powernv/pci-sriov.c:462:7-10: WARNING: Unsigned
>> expression compared with zero: win < 0
>>
>> Reported-by: Tosk Robot
>> Signed-off-by: Kaixu Xia
>
> This seems like the right fix, the value assigned to win can indeed be
> -1 so it should be signed. Thanks for sending the patch.
>
> Reviewed-by: Andrew Donnellan
I'll add:
Fixes: 39efc03e3ee8 ("powerpc/powernv/sriov: Move M64 BAR allocation into a
helper")
Which I think is the culprit as it changed:
if (win >= phb->ioda.m64_bar_idx + 1)
to:
if (win < 0)
cheers
Re: [PATCH V3] sched/rt, powerpc: Prepare for PREEMPT_RT
Wang Qing writes:
> PREEMPT_RT is a separate preemption model, CONFIG_PREEMPT will
> be disabled when CONFIG_PREEMPT_RT is enabled, so we need
> to add CONFIG_PREEMPT_RT output to __die().
>
> Signed-off-by: Wang Qing
Something fairly similar was posted previously.
That time I said:
I don't think there's any point adding the "_RT" to the __die() output
until/if we ever start supporting PREEMPT_RT.
https://lore.kernel.org/linuxppc-dev/87d0ext4q3@mpe.ellerman.id.au/
And I think I still feel the same way. It's not clear powerpc will ever
support PREEMPT_RT, so this would just be confusing to people. And
potentially someone will then send a patch to remove it as dead code.
cheers
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 5006dcb..dec7b81
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -262,10 +262,11 @@ static int __die(const char *str, struct pt_regs *regs,
> long err)
> {
> printk("Oops: %s, sig: %ld [#%d]\n", str, err, ++die_counter);
>
> - printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s %s\n",
> + printk("%s PAGE_SIZE=%luK%s%s%s%s%s%s%s %s\n",
> IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN) ? "LE" : "BE",
> PAGE_SIZE / 1024, get_mmu_str(),
> IS_ENABLED(CONFIG_PREEMPT) ? " PREEMPT" : "",
> +IS_ENABLED(CONFIG_PREEMPT_RT) ? " PREEMPT_RT" : "",
> IS_ENABLED(CONFIG_SMP) ? " SMP" : "",
> IS_ENABLED(CONFIG_SMP) ? (" NR_CPUS=" __stringify(NR_CPUS)) : "",
> debug_pagealloc_enabled() ? " DEBUG_PAGEALLOC" : "",
> --
> 2.7.4
[PATCH] powerpc: Drop -me200 addition to build flags
Currently a build with CONFIG_E200=y will fail with: Error: invalid switch -me200 Error: unrecognized option -me200 Upstream binutils has never supported an -me200 option. Presumably it was supported at some point by either a fork or Freescale internal binutils. We can't support code that we can't even build test, so drop the addition of -me200 to the build flags, so we can at least build with CONFIG_E200=y. Reported-by: Németh Márton Reported-by: kernel test robot Signed-off-by: Michael Ellerman --- More discussion: https://lore.kernel.org/lkml/202011131146.g8dplqdd-...@intel.com --- arch/powerpc/Makefile | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index a4d56f0a41d9..16b8336f91dd 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -248,7 +248,6 @@ KBUILD_CFLAGS += $(call cc-option,-mno-string) cpu-as-$(CONFIG_40x) += -Wa,-m405 cpu-as-$(CONFIG_44x) += -Wa,-m440 cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec) -cpu-as-$(CONFIG_E200) += -Wa,-me200 cpu-as-$(CONFIG_E500) += -Wa,-me500 # When using '-many -mpower4' gas will first try and find a matching power4 -- 2.25.1
Re: Error: invalid switch -me200
Christophe Leroy writes:
> Le 14/11/2020 à 01:20, Segher Boessenkool a écrit :
>> On Fri, Nov 13, 2020 at 12:14:18PM -0800, Nick Desaulniers wrote:
>> Error: invalid switch -me200
>> Error: unrecognized option -me200
>
> 251 cpu-as-$(CONFIG_E200) += -Wa,-me200
>
> Are those all broken configs, or is Kconfig messed up such that
> randconfig can select these when it should not?
Hmmm, looks like this flag does not exist in mainline binutils? There is
a thread in 2010 about this that Segher commented on:
https://lore.kernel.org/linuxppc-dev/9859e645-954d-4d07-8003-ffcd2391a...@kernel.crashing.org/
Guess this config should be eliminated?
>>
>> The help text for this config options says that e200 is used in 55xx,
>> and there *is* an -me5500 GAS flag (which probably does this same
>> thing, too). But is any of this tested, or useful, or wanted?
>>
>> Maybe Christophe knows, cc:ed.
>>
>
> I don't have much clue on this.
Me either.
> But I see on wikipedia that e5500 is a 64 bits powerpc
> (https://en.wikipedia.org/wiki/PowerPC_e5500)
>
> What I see is that NXP seems to provide a GCC version that includes
> aditionnal cpu (e200z0 e200z2
> e200z3 e200z4 e200z6 e200z7):
>
> valid arguments to '-mcpu=' are: 401 403 405 405fp 440 440fp 464 464fp 476
> 476fp 505 601 602 603
> 603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4
> G5 a2 cell e200z0 e200z2
> e200z3 e200z4 e200z6 e200z7 e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e
> native power3 power4
> power5 power5+ power6 power6x power7 power8 powerpc powerpc64 powerpc64le
> rs64 titan "
>
> https://community.nxp.com/t5/MPC5xxx/GCC-generating-not-implemented-instructions/m-p/845049
>
> Apparently based on binutils 2.28
>
> https://www.nxp.com/docs/en/release-note/S32DS-POWER-v1-2-RN.pdf
>
> But that's not exactly -me200 though.
>
> Now, I can't see any defconfig that selects CONFIG_E200, so is that worth
> keeping it in the kernel
> at all ?
There was a commit in 2014 that suggests it worked at least to some
extent then:
3477e71d5319 ("powerpc/booke: Restrict SPE exception handlers to e200/e500
cores")
Presumably there was a non-upstream toolchain where it was supported?
AFAICS the kernel builds OK with just the cpu-as modification removed:
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a4d56f0a41d9..16b8336f91dd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -248,7 +248,6 @@ KBUILD_CFLAGS += $(call cc-option,-mno-string)
cpu-as-$(CONFIG_40x) += -Wa,-m405
cpu-as-$(CONFIG_44x) += -Wa,-m440
cpu-as-$(CONFIG_ALTIVEC) += $(call as-option,-Wa$(comma)-maltivec)
-cpu-as-$(CONFIG_E200) += -Wa,-me200
cpu-as-$(CONFIG_E500) += -Wa,-me500
# When using '-many -mpower4' gas will first try and find a matching power4
So that seems like the obvious fix for now.
I tried booting the resulting kernel in qemu, but I get:
$ qemu-system-ppc -M none -cpu e200 -kernel build\~/vmlinux
Error: Trying to register SPR 574 (23e) twice !
Which is not related AFAIK and indicates the qemu support is broken.
Unless we hear from someone that they're using mainline on an e200 then
it seems like it's a candidate for removal.
cheers
