Re: [PATCH] Raise the minimum GCC version to 5.2
On Sun 2021-05-02 00:15:38, Masahiro Yamada wrote: > The current minimum GCC version is 4.9 except ARCH=arm64 requiring > GCC 5.1. Please don't. I'm still on 4.9 on machine I can't easily update, > Documentation/process/changes.rst | 2 +- > arch/arm64/Kconfig| 2 +- > arch/powerpc/Kconfig | 2 +- > arch/riscv/Kconfig| 2 +- > include/linux/compiler-gcc.h | 6 +- > lib/Kconfig.debug | 2 +- > scripts/min-tool-version.sh | 8 +--- > 7 files changed, 7 insertions(+), 17 deletions(-) and 10 lines of cleanups is really not worth that. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH] Raise the minimum GCC version to 5.2
On Sat, 2021-05-15 at 09:14 +0200, Pavel Machek wrote: > On Sun 2021-05-02 00:15:38, Masahiro Yamada wrote: > > The current minimum GCC version is 4.9 except ARCH=arm64 requiring > > GCC 5.1. > > Please don't. I'm still on 4.9 on machine I can't easily update, Why is that? Later compiler versions are available. http://cdn.kernel.org/pub/tools/crosstool/ Is there some other reason your machine can not have the compiler version updated?
Re: [FSL P50x0] KVM HV doesn't work anymore
Hi All, I bisected today [1] and the bisecting itself was OK but the reverting of the bad commit doesn't solve the issue. Do you have an idea which commit could be resposible for this issue? Maybe the bisecting wasn't successful. I will look in the kernel git log. Maybe there is a commit that affected KVM HV on FSL P50x0 machines. Thanks, Christian [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 On 14 May 2021 at 10:10 am, Christian Zigotzky wrote: Hi All, The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine with KVM HV anymore. I see in the serial console that the uImage doesn't load. I use the following QEMU command for booting: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage-5.13 -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 The kernel boots without KVM HV. Have you already tested KVM HV with the kernel 5.13? Thanks, Christian
Re: [FSL P50x0] KVM HV doesn't work anymore
Le 15/05/2021 à 11:48, Christian Zigotzky a écrit : Hi All, I bisected today [1] and the bisecting itself was OK but the reverting of the bad commit doesn't solve the issue. Do you have an idea which commit could be resposible for this issue? Maybe the bisecting wasn't successful. I will look in the kernel git log. Maybe there is a commit that affected KVM HV on FSL P50x0 machines. If the uImage doesn't load, it may be because of the size of uImage. See https://github.com/linuxppc/issues/issues/208 Is there a significant size difference with and without KVM HV ? Maybe you can try to remove another option to reduce the size of the uImage. Or if you are using gzipped uImage you can try with an lzma uImage. You can find a way to get an lzma uImage here: https://github.com/linuxppc/issues/issues/208#issuecomment-477479951 Christophe Thanks, Christian [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 On 14 May 2021 at 10:10 am, Christian Zigotzky wrote: Hi All, The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine with KVM HV anymore. I see in the serial console that the uImage doesn't load. I use the following QEMU command for booting: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage-5.13 -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 The kernel boots without KVM HV. Have you already tested KVM HV with the kernel 5.13? Thanks, Christian
[Bug 213069] kernel BUG at arch/powerpc/include/asm/book3s/64/hash-4k.h:147! Oops: Exception in kernel mode, sig: 5 [#1]
https://bugzilla.kernel.org/show_bug.cgi?id=213069 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- The bug occurs with DEBUG_VM_PGTABLE=y. When DEBUG_VM_PGTABLE is not set the kernel boots fine. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 15/31] KVM: PPC: Book3S HV: XIVE: Fix mapping of passthrough interrupts
On Fri, 14 May 2021 21:51:51 +0100,
Thomas Gleixner wrote:
>
> On Fri, Apr 30 2021 at 10:03, Cédric Le Goater wrote:
>
> CC: +Marc
Thanks Thomas.
>
> > PCI MSI interrupt numbers are now mapped in a PCI-MSI domain but the
> > underlying calls handling the passthrough of the interrupt in the
> > guest need a number in the XIVE IRQ domain.
> >
> > Use the IRQ data mapped in the XIVE IRQ domain and not the one in the
> > PCI-MSI domain.
> >
> > Exporting irq_get_default_host() might not be the best solution.
> >
> > Cc: Thomas Gleixner
> > Cc: Paul Mackerras
> > Signed-off-by: Cédric Le Goater
> > ---
> > arch/powerpc/kvm/book3s_xive.c | 3 ++-
> > kernel/irq/irqdomain.c | 1 +
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/powerpc/kvm/book3s_xive.c
> > index 3a7da42bed57..81b9f4fc3978 100644
> > --- a/arch/powerpc/kvm/book3s_xive.c
> > +++ b/arch/powerpc/kvm/book3s_xive.c
> > @@ -861,7 +861,8 @@ int kvmppc_xive_set_mapped(struct kvm *kvm, unsigned
> > long guest_irq,
> > struct kvmppc_xive *xive = kvm->arch.xive;
> > struct kvmppc_xive_src_block *sb;
> > struct kvmppc_xive_irq_state *state;
> > - struct irq_data *host_data = irq_get_irq_data(host_irq);
> > + struct irq_data *host_data =
> > + irq_domain_get_irq_data(irq_get_default_host(), host_irq);
> > unsigned int hw_irq = (unsigned int)irqd_to_hwirq(host_data);
> > u16 idx;
> > u8 prio;
> > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
> > index d10ab1d689d5..8a073d1ce611 100644
> > --- a/kernel/irq/irqdomain.c
> > +++ b/kernel/irq/irqdomain.c
> > @@ -481,6 +481,7 @@ struct irq_domain *irq_get_default_host(void)
> > {
> > return irq_default_domain;
> > }
> > +EXPORT_SYMBOL_GPL(irq_get_default_host);
> >
> > static void irq_domain_clear_mapping(struct irq_domain *domain,
> > irq_hw_number_t hwirq)
>
Is there any reason why we should add more users of the "default host"
fallback? I would really hope that new code would actually track their
irqdomain in a more fine-grained way, specially when using the
hierarchical MSi setup, which seems to be the goal of this series.
Don't you have enough topology information that you can make use of to
correctly assign a domain identifier (of_node or otherwise)?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
[Bug 213079] New: IRQ problems and crashes on a PowerMac G5 with 5.13-rc1
https://bugzilla.kernel.org/show_bug.cgi?id=213079 Bug ID: 213079 Summary: IRQ problems and crashes on a PowerMac G5 with 5.13-rc1 Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.13-rc1 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 296759 --> https://bugzilla.kernel.org/attachment.cgi?id=296759&action=edit dmesg (5.13-rc1, PowerMac G5 11,2) With v5.13-rc1 I get IRQ problems and crashes on my G5 sooner or later. IRQ 63 is my NVMe SSD. [...] irq 63: nobody cared (try booting with the "irqpoll" option) CPU: 1 PID: 11783 Comm: emerge Tainted: GW 5.13.0-rc1-PowerMacG5 #3 Call Trace: [cffefae0] [c0549790] .dump_stack+0xe0/0x13c (unreliable) [cffefb80] [c00def44] .__report_bad_irq+0x34/0xf0 [cffefc20] [c00dee2c] .note_interrupt+0x258/0x300 [cffefce0] [c00db0a8] .handle_irq_event_percpu+0x64/0x90 [cffefd70] [c00db118] .handle_irq_event+0x44/0x70 [cffefe00] [c00e0530] .handle_fasteoi_irq+0xac/0x158 [cffefea0] [c00da164] .generic_handle_irq+0x38/0x58 [cffeff10] [c0011674] .__do_irq+0x15c/0x238 [cffeff90] [c0012068] .do_IRQ+0x180/0x188 [c0014d357d70] [c0011f88] .do_IRQ+0xa0/0x188 [c0014d357e10] [c0007f94] hardware_interrupt_common_virt+0x1a4/0x1b0 --- interrupt: 500 at 0x3fffb07a1a9c NIP: 3fffb07a1a9c LR: 3fffb07a3d08 CTR: 3fffb074cb30 REGS: c0014d357e80 TRAP: 0500 Tainted: GW (5.13.0-rc1-PowerMacG5) MSR: 9000f032 CR: 22482820 XER: 2000 IRQMASK: 0 GPR00: 3fffb07a3d08 3fffe84d07a0 3fffb0ad1200 3fffa8131100 GPR04: 3fffa9ea4bd0 a5a8b016e7fdc57d 3fffe84d0810 3fffb0aa7ac0 GPR08: 3fffb0ab3708 3fffab4eb870 GPR12: 3fffb07b92a0 3fffb0b8e850 3fffe84d0a58 00014df42388 GPR16: 3fffe84d0a70 3fffafbf54c0 GPR20: 00014df42338 00014c677878 GPR24: 3fffafc0b5b0 00014c677830 3fffafcc8a50 a5a8b016e7fdc57d GPR28: 3fffa863bcc0 3fffa8131100 3fffa9ea4bd0 3fffa8131100 NIP [3fffb07a1a9c] 0x3fffb07a1a9c LR [3fffb07a3d08] 0x3fffb07a3d08 --- interrupt: 500 handlers: [<370eb0ba>] .nvme_irq [<370eb0ba>] .nvme_irq Disabling IRQ #63 Call Trace: Kernel panic - not syncing: corrupted stack end detected inside scheduler CPU: 0 PID: 814 Comm: kworker/u4:2 Tainted: GW 5.13.0-rc1-PowerMacG5 #3 Workqueue: writeback .wb_workfn (flush-254:1) [c0007db5ab40] [c0549790] .dump_stack+0xe0/0x13c (unreliable) [c0007db5abe0] [c00680dc] .panic+0x168/0x430 [c0007db5ac90] [c0811e40] .__schedule+0x80/0x840 [c0007db5ad70] [c081274c] .preempt_schedule_common+0x28/0x48 [c0007db5adf0] [c081279c] .__cond_resched+0x30/0x4c [c0007db5ae70] [c01c6a98] .mempool_alloc+0x38/0x1a4 [c0007db5af50] [c04a1a70] .bio_alloc_bioset+0x94/0x174 [c0007db5b000] [c0354840] .ext4_bio_write_page+0x314/0x480 [c0007db5b0c0] [c03334d4] .mpage_submit_page+0x70/0xa0 [c0007db5b140] [c0333630] .mpage_process_page_bufs+0x12c/0x18c [c0007db5b1d0] [c03338b8] .mpage_prepare_extent_to_map+0x1f8/0x228 [c0007db5b320] [c0339088] .ext4_writepages+0x360/0xe5c [c0007db5b5d0] [c01cee84] .do_writepages+0x54/0xa0 [c0007db5b650] [c02a49bc] .__writeback_single_inode+0x100/0x560 [c0007db5b700] [c02a53d8] .writeback_sb_inodes+0x2dc/0x4c8 [c0007db5b880] [c02a5654] .__writeback_inodes_wb+0x90/0xcc [c0007db5b930] [c02a58c0] .wb_writeback+0x230/0x3dc [c0007db5ba50] [c02a6790] .wb_workfn+0x380/0x460 [c0007db5bbb0] [c00890a0] .process_one_work+0x318/0x4dc [c0007db5bca0] [c0089730] .worker_thread+0x224/0x290 [c0007db5bd60] [c0091200] .kthread+0x134/0x13c [c0007db5be10] [c000bbf4] .ret_from_kernel_thread+0x58/0x64 Rebooting in 120 seconds.. # lspci -vv -s 0001:08:00.0 0001:08:00.0 Non-Volatile memory controller: Intel Corporation SSD Pro 7600p/760p/E 6100p Series (rev 03) (prog-if 02 [NVM Express]) Subsystem: Intel Corporation SSD Pro 7600p/760p/E 6100p Series [NVM Express] Device tree node: /sys/firmware/devicetree/base/ht@0,f200/pci@5/pci8086,390b@0 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVS
[Bug 213079] IRQ problems and crashes on a PowerMac G5 with 5.13-rc1
https://bugzilla.kernel.org/show_bug.cgi?id=213079 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 296761 --> https://bugzilla.kernel.org/attachment.cgi?id=296761&action=edit kernel .config (5.13-rc1, PowerMac G5 11,2) -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 213079] IRQ problems and crashes on a PowerMac G5 with 5.13-rc1
https://bugzilla.kernel.org/show_bug.cgi?id=213079 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Hmm... Just also happened on 5.12.3. But without the Kernel panic (yet). [...] irq 63: nobody cared (try booting with the "irqpoll" option) Call Trace: CPU: 1 PID: 43491 Comm: emerge Tainted: GW 5.12.3-gentoo-PowerMacG5 #2 [cffefae0] [c053950c] .dump_stack+0xe0/0x13c (unreliable) [cffefb80] [c00ddb68] .__report_bad_irq+0x34/0xf0 [cffefc20] [c00dda50] .note_interrupt+0x250/0x2f8 [cffefce0] [c00d9cf8] .handle_irq_event_percpu+0x64/0x90 [cffefd70] [c00d9d68] .handle_irq_event+0x44/0x70 [cffefe00] [c00df164] .handle_fasteoi_irq+0xac/0x158 [cffefea0] [c00d8db8] .generic_handle_irq+0x38/0x58 [cffeff10] [c0011314] .__do_irq+0x15c/0x238 [cffeff90] [c001fe04] .call_do_irq+0x14/0x24 [c00056e2fd70] [c001154c] .do_IRQ+0x15c/0x164 [c00056e2fe10] [c0007d38] hardware_interrupt_common_virt+0x158/0x160 --- interrupt: 500 at 0x3fffb8a21520 handlers: NIP: 3fffb8a21520 LR: 3fffb8a214a0 CTR: 3fffb8ae6d20 REGS: c00056e2fe80 TRAP: 0500 Tainted: GW (5.12.3-gentoo-PowerMacG5) MSR: 9200f032 CR: 42482824 XER: 2000 IRQMASK: 0 GPR00: 3fffb8a214a0 3fffdb199650 3fffb8df7200 00014e8ddc60 GPR04: 3fffb210e000 95bfd31b66b69e10 3fffdb199478 00024d50 GPR08: 00014cb987c0 0002 GPR12: 3fffb8ae0e50 3fffb8eb4850 3fffdb199a58 00014e8ddf60 GPR16: 3fffdb199a70 0001 00014b5d8460 GPR20: 0002 00014e8ddf38 3fffb6b176e8 GPR24: 00014c126958 3fffb2030390 00014b94c380 00014b5d8460 GPR28: 00014c1267f0 00014c126a60 00014c1267f0 NIP [3fffb8a21520] 0x3fffb8a21520 LR [3fffb8a214a0] 0x3fffb8a214a0 --- interrupt: 500 [<0e5af612>] .nvme_irq [<0e5af612>] .nvme_irq Disabling IRQ #63 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [FSL P50x0] KVM HV doesn't work anymore
On 15 May 2021 at 12:08pm Christophe Leroy wrote: Le 15/05/2021 à 11:48, Christian Zigotzky a écrit : Hi All, I bisected today [1] and the bisecting itself was OK but the reverting of the bad commit doesn't solve the issue. Do you have an idea which commit could be resposible for this issue? Maybe the bisecting wasn't successful. I will look in the kernel git log. Maybe there is a commit that affected KVM HV on FSL P50x0 machines. If the uImage doesn't load, it may be because of the size of uImage. See https://github.com/linuxppc/issues/issues/208 Is there a significant size difference with and without KVM HV ? Maybe you can try to remove another option to reduce the size of the uImage. I tried it but it doesn't solve the issue. The uImage works without KVM HV in a virtual e5500 QEMU machine. -Christian Or if you are using gzipped uImage you can try with an lzma uImage. You can find a way to get an lzma uImage here: https://github.com/linuxppc/issues/issues/208#issuecomment-477479951 Christophe Thanks, Christian [1] https://forum.hyperion-entertainment.com/viewtopic.php?p=53209#p53209 On 14 May 2021 at 10:10 am, Christian Zigotzky wrote: Hi All, The RC1 of kernel 5.13 doesn't boot in a virtual e5500 QEMU machine with KVM HV anymore. I see in the serial console that the uImage doesn't load. I use the following QEMU command for booting: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m 1024 -kernel uImage-5.13 -drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev user,id=mynet0 -device e1000,netdev=mynet0 -append "rw root=/dev/vda" -device virtio-vga -device virtio-mouse-pci -device virtio-keyboard-pci -device pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 The kernel boots without KVM HV. Have you already tested KVM HV with the kernel 5.13? Thanks, Christian
[Bug 213079] IRQ problems and crashes on a PowerMac G5 with 5.12.3
https://bugzilla.kernel.org/show_bug.cgi?id=213079 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Kernel Version|5.13-rc1|5.12.3 Summary|IRQ problems and crashes on |IRQ problems and crashes on |a PowerMac G5 with 5.13-rc1 |a PowerMac G5 with 5.12.3 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- Some time after the "irq 63: nobody cared" on 5.12.3: [...] --- interrupt: 500 [<0e5af612>] .nvme_irq [<0e5af612>] .nvme_irq Disabling IRQ #63 Call Trace: Kernel panic - not syncing: corrupted stack end detected inside scheduler CPU: 0 PID: 105549 Comm: kworker/u4:1 Tainted: GW 5.12.3-gentoo-PowerMacG5 #2 Workqueue: 0x0 (flush-259:0) [c00078dc79f0] [c053950c] .dump_stack+0xe0/0x13c (unreliable) [c00078dc7a90] [c0066074] .panic+0x168/0x430 [c00078dc7b40] [c07f19f0] .__schedule+0x80/0x848 [c00078dc7c20] [c07f2270] .schedule+0xb8/0x110 [c00078dc7ca0] [c0086d18] .worker_thread+0x278/0x290 [c00078dc7d60] [c008e75c] .kthread+0x134/0x13c [c00078dc7e10] [c000b1f4] .ret_from_kernel_thread+0x58/0x64 Rebooting in 120 seconds.. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
On Thu, Apr 22, 2021 at 11:13:19AM +0530, Aneesh Kumar K.V wrote:
> No functional change in this patch
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> .../include/asm/book3s/64/tlbflush-radix.h| 19 +++-
> arch/powerpc/include/asm/book3s/64/tlbflush.h | 23 ---
> arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +--
> arch/powerpc/mm/book3s64/radix_tlb.c | 29 +++
> 4 files changed, 42 insertions(+), 33 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> index 8b33601cdb9d..171441a43b35 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
> @@ -56,15 +56,18 @@ static inline void radix__flush_all_lpid_guest(unsigned
> int lpid)
> }
> #endif
>
> -extern void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
> -unsigned long start, unsigned long
> end);
> -extern void radix__flush_tlb_range_psize(struct mm_struct *mm, unsigned long
> start,
> - unsigned long end, int psize);
> -extern void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
> -unsigned long start, unsigned long end);
> -extern void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long
> start,
> +void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
> + unsigned long start, unsigned long end,
> + bool flush_pwc);
> +void radix__flush_pmd_tlb_range(struct vm_area_struct *vma,
> + unsigned long start, unsigned long end,
> + bool flush_pwc);
> +void radix__flush_tlb_pwc_range_psize(struct mm_struct *mm, unsigned long
> start,
> + unsigned long end, int psize, bool
> flush_pwc);
> +void radix__flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
> unsigned long end);
> -extern void radix__flush_tlb_kernel_range(unsigned long start, unsigned long
> end);
> +void radix__flush_tlb_kernel_range(unsigned long start, unsigned long end);
> +
>
> extern void radix__local_flush_tlb_mm(struct mm_struct *mm);
> extern void radix__local_flush_all_mm(struct mm_struct *mm);
> diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> index 215973b4cb26..f9f8a3a264f7 100644
> --- a/arch/powerpc/include/asm/book3s/64/tlbflush.h
> +++ b/arch/powerpc/include/asm/book3s/64/tlbflush.h
> @@ -45,13 +45,30 @@ static inline void tlbiel_all_lpid(bool radix)
> hash__tlbiel_all(TLB_INVAL_SCOPE_LPID);
> }
>
> +static inline void flush_pmd_tlb_pwc_range(struct vm_area_struct *vma,
> +unsigned long start,
> +unsigned long end,
> +bool flush_pwc)
> +{
> + if (radix_enabled())
> + return radix__flush_pmd_tlb_range(vma, start, end, flush_pwc);
> + return hash__flush_tlb_range(vma, start, end);
^^
> +}
>
> #define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
> unsigned long start, unsigned long end)
> +{
> + return flush_pmd_tlb_pwc_range(vma, start, end, false);
^^
Doesn't that cause build warnings/errors all over the place ?
Guenter
Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
On Sat, 15 May 2021 09:35:25 -0700 Guenter Roeck wrote:
> >
> > #define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
> > static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
>
> >unsigned long start, unsigned long end)
> > +{
> > + return flush_pmd_tlb_pwc_range(vma, start, end, false);
> ^^
>
> Doesn't that cause build warnings/errors all over the place ?
It will, thanks. I queued a fix.
Re: [PATCH] powerpc/interrupts: Fix kuep_unlock() call
On Thu, 6 May 2021 14:49:45 + (UTC), Christophe Leroy wrote: > Same as kuap_user_restore(), kuep_unlock() has to be called when > really returning to user, that is in interrupt_exit_user_prepare(), > not in interrupt_exit_prepare(). Applied to powerpc/fixes. [1/1] powerpc/interrupts: Fix kuep_unlock() call https://git.kernel.org/powerpc/c/a78339698ab1f43435fbe67fcd6de8f4f6eb9eec cheers
Re: [PATCH] powerpc/legacy_serial: Fix UBSAN: array-index-out-of-bounds
On Sat, 8 May 2021 06:36:21 + (UTC), Christophe Leroy wrote: > UBSAN complains when a pointer is calculated with invalid > 'legacy_serial_console' index, allthough the index is verified > before dereferencing the pointer. > > Fix it by checking 'legacy_serial_console' validity before > calculating pointers. Applied to powerpc/fixes. [1/1] powerpc/legacy_serial: Fix UBSAN: array-index-out-of-bounds https://git.kernel.org/powerpc/c/63970f3c37e75997ed86dbdfdc83df35f2152bb1 cheers
Re: [PATCH] powerpc/signal: Fix possible build failure with unsafe_copy_fpr_{to/from}_user
On Sat, 8 May 2021 09:25:44 + (UTC), Christophe Leroy wrote:
> When neither CONFIG_VSX nor CONFIG_PPC_FPU_REGS are selected,
> unsafe_copy_fpr_to_user() and unsafe_copy_fpr_from_user() are
> doing nothing.
>
> Then, unless the 'label' operand is used elsewhere, GCC complains
> about it being defined but not used.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/signal: Fix possible build failure with
unsafe_copy_fpr_{to/from}_user
https://git.kernel.org/powerpc/c/bc581dbab26edf0b6acc98c76943b4a0c7d672a2
cheers
Re: [PATCH] powerpc/syscall: Calling kuap_save_and_lock() is wrong
On Thu, 6 May 2021 11:56:31 + (UTC), Christophe Leroy wrote: > kuap_save_and_lock() is only for interrupts inside kernel. > > system call are only from user, calling kuap_save_and_lock() > is wrong. Applied to powerpc/fixes. [1/1] powerpc/syscall: Calling kuap_save_and_lock() is wrong https://git.kernel.org/powerpc/c/5d510ed78bcfcbbd3b3891cbe79cd7543bce1d05 cheers
Re: [PATCH] powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT
On Sat, 8 May 2021 09:25:32 + (UTC), Christophe Leroy wrote: > Building kernel mainline with GCC 11 leads to following failure > when starting 'init': > > init[1]: bad frame in sys_sigreturn: 7ff5a900 nip 001083cc lr 001083c4 > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b > > This is an issue due to a segfault happening in > __unsafe_restore_general_regs() in a loop copying registers from user > to kernel: > > [...] Applied to powerpc/fixes. [1/1] powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT https://git.kernel.org/powerpc/c/7315e457d6bc342d06ba0b7ee498221c5237a547 cheers
Re: [PATCH 1/2] powerpc/64s: Fix entry flush patching w/strict RWX & hash
On Fri, 14 May 2021 00:07:59 +1000, Michael Ellerman wrote: > The entry flush mitigation can be enabled/disabled at runtime. When this > happens it results in the kernel patching its own instructions to > enable/disable the mitigation sequence. > > With strict kernel RWX enabled instruction patching happens via a > secondary mapping of the kernel text, so that we don't have to make the > primary mapping writable. With the hash MMU this leads to a hash fault, > which causes us to execute the exception entry which contains the entry > flush mitigation. > > [...] Applied to powerpc/fixes. [1/2] powerpc/64s: Fix entry flush patching w/strict RWX & hash https://git.kernel.org/powerpc/c/49b39ec248af863781a13aa6d81c5f69a2928094 [2/2] powerpc/64s: Fix stf mitigation patching w/strict RWX & hash https://git.kernel.org/powerpc/c/5b48ba2fbd77bc68feebd336ffad5ff166782bde cheers
Re: [PATCH] KVM: PPC: Book3S HV: Fix kvm_unmap_gfn_range_hv() for Hash MMU
On Tue, 11 May 2021 20:54:59 +1000, Michael Ellerman wrote:
> Commit 32b48bf8514c ("KVM: PPC: Book3S HV: Fix conversion to gfn-based
> MMU notifier callbacks") fixed kvm_unmap_gfn_range_hv() by adding a for
> loop over each gfn in the range.
>
> But for the Hash MMU it repeatedly calls kvm_unmap_rmapp() with the
> first gfn of the range, rather than iterating through the range.
>
> [...]
Applied to powerpc/fixes.
[1/1] KVM: PPC: Book3S HV: Fix kvm_unmap_gfn_range_hv() for Hash MMU
https://git.kernel.org/powerpc/c/da3bb206c9ceb0736d9e2897ea697acabad35833
cheers
Re: [PATCH v2 1/2] powerpc/64s: Fix crashes when toggling stf barrier
On Thu, 6 May 2021 14:49:58 +1000, Michael Ellerman wrote: > The STF (store-to-load forwarding) barrier mitigation can be > enabled/disabled at runtime via a debugfs file (stf_barrier), which > causes the kernel to patch itself to enable/disable the relevant > mitigations. > > However depending on which mitigation we're using, it may not be safe to > do that patching while other CPUs are active. For example the following > crash: > > [...] Applied to powerpc/fixes. [1/2] powerpc/64s: Fix crashes when toggling stf barrier https://git.kernel.org/powerpc/c/8ec7791bae1327b1c279c5cd6e929c3b12daaf0a [2/2] powerpc/64s: Fix crashes when toggling entry flush barrier https://git.kernel.org/powerpc/c/aec86b052df6541cc97c5fca44e5934cbea4963b cheers
Re: [PATCH] powerpc/64e/interrupt: fix nvgprs being clobbered
On Fri, 14 May 2021 14:40:08 +1000, Nicholas Piggin wrote: > Some interrupt handlers have an "extra" that saves 1 or 2 registers > (r14, r15) in the paca save area and makes them available to use by the > handler. > > The change to always save nvgprs in exception handlers lead to some > interrupt handlers saving those scratch r14 / r15 registers into the > interrupt frame's GPR saves, which get restored on interrupt exit. > > [...] Applied to powerpc/fixes. [1/1] powerpc/64e/interrupt: fix nvgprs being clobbered https://git.kernel.org/powerpc/c/c6ac667b07996929835b512de0e9a988977e6abc cheers
Re: [PATCH] powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled
On Mon, 3 May 2021 21:17:08 +1000, Nicholas Piggin wrote: > scv support introduced the notion of code that implicitly soft-masks > irqs due to the instruction addresses. This is required because scv > enters the kernel with MSR[EE]=1. > > If a NMI (including soft-NMI) interrupt hits when we are implicitly > soft-masked then its regs->softe does not reflect this because it is > derived from the explicit soft mask state (paca->irq_soft_mask). This > makes arch_irq_disabled_regs(regs) return false. > > [...] Applied to powerpc/fixes. [1/1] powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled https://git.kernel.org/powerpc/c/4ec5feec1ad029bdf7d49bc50ccc0c195eeabe93 cheers
Re: [PATCH v2 0/4] Fix queued spinlocks and a bit more
On Sat, 8 May 2021 20:14:51 +1000, Nicholas Piggin wrote: > This didn't seem to send properly, apologies if you get a duplicate. > > Patch 1 is the important fix. 2 might fix something, although I haven't > provoked a crash yet. > > Patch 3 is a small cleanup, and patch 4 I think is the right thing to do > but these could wait for later. > > [...] Applied to powerpc/fixes. [1/4] powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks https://git.kernel.org/powerpc/c/2c8c89b95831f46a2fb31a8d0fef4601694023ce [2/4] powerpc/pseries: Don't trace hcall tracing wrapper https://git.kernel.org/powerpc/c/a3f1a39a5643d5c5ed3eee4edd933e0ebfeeed6e [3/4] powerpc/pseries: use notrace hcall variant for H_CEDE idle https://git.kernel.org/powerpc/c/7058f4b13edd9dd2cb3c5b4fe340d8307dbe0208 [4/4] powerpc/pseries: warn if recursing into the hcall tracing code https://git.kernel.org/powerpc/c/4f242fc5f2e24412b89e934dad025b10293b2712 cheers
Re: [PATCH v5 5/9] powerpc/mm/book3s64: Update tlb flush routines to take a page walk cache flush argument
On 5/15/21 1:41 PM, Andrew Morton wrote:
On Sat, 15 May 2021 09:35:25 -0700 Guenter Roeck wrote:
#define __HAVE_ARCH_FLUSH_PMD_TLB_RANGE
static inline void flush_pmd_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
+{
+ return flush_pmd_tlb_pwc_range(vma, start, end, false);
^^
Doesn't that cause build warnings/errors all over the place ?
It will, thanks. I queued a fix.
Also in mm/mremap.c, in case you didn't see it:
#ifndef flush_pte_tlb_pwc_range
#define flush_pte_tlb_pwc_range flush_pte_tlb_pwc_range
static inline void flush_pte_tlb_pwc_range(struct vm_area_struct *vma,
unsigned long start,
unsigned long end)
{
return flush_tlb_range(vma, start, end);
}
[GIT PULL] Please pull powerpc/linux.git powerpc-5.13-3 tag
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.13:
The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:
Linux 5.13-rc1 (2021-05-09 14:17:44 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
tags/powerpc-5.13-3
for you to fetch changes up to c6ac667b07996929835b512de0e9a988977e6abc:
powerpc/64e/interrupt: Fix nvgprs being clobbered (2021-05-14 17:28:54 +1000)
- --
powerpc fixes for 5.13 #3
- Fix a regression in the conversion of the 64-bit BookE interrupt entry to C.
- Fix KVM hosts running with the hash MMU since the recent KVM gfn changes.
- Fix a deadlock in our paravirt spinlocks when hcall tracing is enabled.
- Several fixes for oopses in our runtime code patching for security
mitigations.
- A couple of minor fixes for the recent conversion of 32-bit interrupt
entry/exit to C.
- Fix __get_user() causing spurious crashes in sigreturn due to a bad inline
asm
constraint, spotted with GCC 11.
- A fix for the way we track IRQ masking state vs NMI interrupts when using
the new scv
system call entry path.
- A couple more minor fixes.
Thanks to: Cédric Le Goater, Christian Zigotzky, Christophe Leroy, Naveen N.
Rao, Nicholas
Piggin Paul Menzel, Sean Christopherson.
- --
Christophe Leroy (5):
powerpc/interrupts: Fix kuep_unlock() call
powerpc/syscall: Calling kuap_save_and_lock() is wrong
powerpc/uaccess: Fix __get_user() with CONFIG_CC_HAS_ASM_GOTO_OUTPUT
powerpc/signal: Fix possible build failure with
unsafe_copy_fpr_{to/from}_user
powerpc/legacy_serial: Fix UBSAN: array-index-out-of-bounds
Michael Ellerman (5):
KVM: PPC: Book3S HV: Fix kvm_unmap_gfn_range_hv() for Hash MMU
powerpc/64s: Fix crashes when toggling stf barrier
powerpc/64s: Fix crashes when toggling entry flush barrier
powerpc/64s: Fix entry flush patching w/strict RWX & hash
powerpc/64s: Fix stf mitigation patching w/strict RWX & hash
Nicholas Piggin (6):
powerpc/pseries: Fix hcall tracing recursion in pv queued spinlocks
powerpc/pseries: Don't trace hcall tracing wrapper
powerpc/pseries: use notrace hcall variant for H_CEDE idle
powerpc/pseries: warn if recursing into the hcall tracing code
powerpc/64s: Make NMI record implicitly soft-masked code as irqs disabled
powerpc/64e/interrupt: Fix nvgprs being clobbered
arch/powerpc/include/asm/hvcall.h | 3 +
arch/powerpc/include/asm/interrupt.h | 9 +-
arch/powerpc/include/asm/paravirt.h | 22 +++-
arch/powerpc/include/asm/plpar_wrappers.h | 6 +-
arch/powerpc/include/asm/uaccess.h| 2 +-
arch/powerpc/kernel/exceptions-64e.S | 38 ---
arch/powerpc/kernel/interrupt.c | 4 +-
arch/powerpc/kernel/legacy_serial.c | 7 +-
arch/powerpc/kernel/signal.h | 4 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 2 +-
arch/powerpc/lib/feature-fixups.c | 114 +++-
arch/powerpc/platforms/pseries/hvCall.S | 10 ++
arch/powerpc/platforms/pseries/lpar.c | 29 +++--
13 files changed, 175 insertions(+), 75 deletions(-)
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmCgWe8ACgkQUevqPMjh
pYDZqg//RzF68ywTKG51T3JmOjVfvkptpEWZOQ52LCwpMQYvMQc+CSnBjEFoNyuS
bIA0xlg0/1xBXNMtPVgNVk7WgDa/yvahVlX3rIuWt4Uhqv6u6Z1fw7aYaGIDH3b2
akRvSvVWYyv87LlMEtxDOHncH1u8Q6E3YW4JM6eaQwjD2XqqeiTYKXUaZATTmepc
GruEdNK5239LkmxMnyFvxCDDyHb8YyCZORHp/l4U+l005/dkM7ZyzHSA1LMekVSB
LrW5q/KjdQW3EC2WDLijSCcshWujOf2MGvaZkmB/TvPtqxsOf3tLZAeEfaObbUrX
6mqe93CtUk1CRNECkqCxF/sO5wq2SJmKx1XTfVR2CvDDg1ZmisesiRHtYk6Dl2Bw
84+5IKwthgTauib3YKyoqXUpfIL8j8qg3M/9WVI6LG+ujPoSD0whPHdqTymqFfwA
ONDT4cSDvBMAtw63cVnWEDgqdrAwTFAr0i+7loWkKeKJv9mxxfGX7MgiglQobDys
xGAOjLnetsD4+JWJMqqrm0ilAKDb+m4stvU7bo/gpWcs6kvxDt2JCOEbJCoqujzQ
B0Tl9H6cyoxhfEnZ7AKzQrGdFg+zUNQ0w5AWslriE5OZcq6vKlgYyVQFeX7t+6vb
Me/YIEBbhPefVZdDD4KZp49PDw+5DgqVJgvMpsrqaRoorZEHni0=
=VnK3
-END PGP SIGNATURE-
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.13-3 tag
The pull request you sent on Sun, 16 May 2021 09:35:30 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.13-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/63d1cb53e26a9a4168b84a8981b225c0a9cfa235 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
