Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On Tue, Nov 3, 2020 at 1:39 AM Cédric Le Goater wrote: > > On 10/14/20 4:55 AM, Alexey Kardashevskiy wrote: > > > > How do you remove PHBs exactly? There is no such thing in the powernv > > platform, I thought someone added this and you are fixing it but no. PHBs > > on powernv are created at the boot time and there is no way to remove them, > > you can only try removing all the bridges. > > yes. I noticed that later when proposing the fix for the double > free. > > > So what exactly are you doing? > > What you just said above, with the commands : > > echo 1 > /sys/devices/pci0031\:00/0031\:00\:00.0/remove > echo 1 > /sys/devices/pci0031\:00/pci_bus/0031\:00/rescan Right, so that'll remove the root port device (and Bus 01 beneath it), but the PHB itself is still there. If it was removed the root bus would also disappear.
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 10/14/20 4:55 AM, Alexey Kardashevskiy wrote: > > > On 23/09/2020 17:06, Cédric Le Goater wrote: >> On 9/23/20 2:33 AM, Qian Cai wrote: >>> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: When a passthrough IO adapter is removed from a pseries machine using hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS to clear all page table entries related to the adapter. If some are still present, the RTAS call which isolates the PCI slot returns error 9001 "valid outstanding translations" and the removal of the IO adapter fails. This is because when the PHBs are scanned, Linux maps automatically the INTx interrupts in the Linux interrupt number space but these are never removed. To solve this problem, we introduce a PPC platform specific pcibios_remove_bus() routine which clears all interrupt mappings when the bus is removed. This also clears the associated page table entries of the ESB pages when using XIVE. For this purpose, we record the logical interrupt numbers of the mapped interrupt under the PHB structure and let pcibios_remove_bus() do the clean up. Since some PCI adapters, like GPUs, use the "interrupt-map" property to describe interrupt mappings other than the legacy INTx interrupts, we can not restrict the size of the mapping array to PCI_NUM_INTX. The number of interrupt mappings is computed from the "interrupt-map" property and the mapping array is allocated accordingly. Cc: "Oliver O'Halloran" Cc: Alexey Kardashevskiy Signed-off-by: Cédric Le Goater >>> >>> Some syscall fuzzing will trigger this on POWER9 NV where the traces >>> pointed to >>> this patch. >>> >>> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config >> >> OK. The patch is missing a NULL assignement after kfree() and that >> might be the issue. >> >> I did try PHB removal under PowerNV, so I would like to understand >> how we managed to remove twice the PCI bus and possibly reproduce. >> Any chance we could grab what the syscall fuzzer (syzkaller) did ? > > > How do you remove PHBs exactly? There is no such thing in the powernv > platform, I thought someone added this and you are fixing it but no. PHBs on > powernv are created at the boot time and there is no way to remove them, you > can only try removing all the bridges. yes. I noticed that later when proposing the fix for the double free. > So what exactly are you doing? What you just said above, with the commands : echo 1 > /sys/devices/pci0031\:00/0031\:00\:00.0/remove echo 1 > /sys/devices/pci0031\:00/pci_bus/0031\:00/rescan C.
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 23/09/2020 17:06, Cédric Le Goater wrote: On 9/23/20 2:33 AM, Qian Cai wrote: On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: When a passthrough IO adapter is removed from a pseries machine using hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS to clear all page table entries related to the adapter. If some are still present, the RTAS call which isolates the PCI slot returns error 9001 "valid outstanding translations" and the removal of the IO adapter fails. This is because when the PHBs are scanned, Linux maps automatically the INTx interrupts in the Linux interrupt number space but these are never removed. To solve this problem, we introduce a PPC platform specific pcibios_remove_bus() routine which clears all interrupt mappings when the bus is removed. This also clears the associated page table entries of the ESB pages when using XIVE. For this purpose, we record the logical interrupt numbers of the mapped interrupt under the PHB structure and let pcibios_remove_bus() do the clean up. Since some PCI adapters, like GPUs, use the "interrupt-map" property to describe interrupt mappings other than the legacy INTx interrupts, we can not restrict the size of the mapping array to PCI_NUM_INTX. The number of interrupt mappings is computed from the "interrupt-map" property and the mapping array is allocated accordingly. Cc: "Oliver O'Halloran" Cc: Alexey Kardashevskiy Signed-off-by: Cédric Le Goater Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed to this patch. .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config OK. The patch is missing a NULL assignement after kfree() and that might be the issue. I did try PHB removal under PowerNV, so I would like to understand how we managed to remove twice the PCI bus and possibly reproduce. Any chance we could grab what the syscall fuzzer (syzkaller) did ? How do you remove PHBs exactly? There is no such thing in the powernv platform, I thought someone added this and you are fixing it but no. PHBs on powernv are created at the boot time and there is no way to remove them, you can only try removing all the bridges. So what exactly are you doing? -- Alexey
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
Qian Cai writes: > On Wed, 2020-09-23 at 09:06 +0200, Cédric Le Goater wrote: >> On 9/23/20 2:33 AM, Qian Cai wrote: >> > On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: >> > > When a passthrough IO adapter is removed from a pseries machine using >> > > hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the >> > > guest OS to clear all page table entries related to the adapter. If >> > > some are still present, the RTAS call which isolates the PCI slot >> > > returns error 9001 "valid outstanding translations" and the removal of >> > > the IO adapter fails. This is because when the PHBs are scanned, Linux >> > > maps automatically the INTx interrupts in the Linux interrupt number >> > > space but these are never removed. >> > > >> > > To solve this problem, we introduce a PPC platform specific >> > > pcibios_remove_bus() routine which clears all interrupt mappings when >> > > the bus is removed. This also clears the associated page table entries >> > > of the ESB pages when using XIVE. >> > > >> > > For this purpose, we record the logical interrupt numbers of the >> > > mapped interrupt under the PHB structure and let pcibios_remove_bus() >> > > do the clean up. >> > > >> > > Since some PCI adapters, like GPUs, use the "interrupt-map" property >> > > to describe interrupt mappings other than the legacy INTx interrupts, >> > > we can not restrict the size of the mapping array to PCI_NUM_INTX. The >> > > number of interrupt mappings is computed from the "interrupt-map" >> > > property and the mapping array is allocated accordingly. >> > > >> > > Cc: "Oliver O'Halloran" >> > > Cc: Alexey Kardashevskiy >> > > Signed-off-by: Cédric Le Goater >> > >> > Some syscall fuzzing will trigger this on POWER9 NV where the traces >> > pointed >> > to >> > this patch. >> > >> > .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config >> >> OK. The patch is missing a NULL assignement after kfree() and that >> might be the issue. >> >> I did try PHB removal under PowerNV, so I would like to understand >> how we managed to remove twice the PCI bus and possibly reproduce. >> Any chance we could grab what the syscall fuzzer (syzkaller) did ? > > Any update on this? Maybe Michael or Stephen could drop this for now, so our > fuzzing could continue to find something else new? Someone send me a revert? cheers
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On Wed, 2020-09-23 at 09:06 +0200, Cédric Le Goater wrote: > On 9/23/20 2:33 AM, Qian Cai wrote: > > On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: > > > When a passthrough IO adapter is removed from a pseries machine using > > > hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the > > > guest OS to clear all page table entries related to the adapter. If > > > some are still present, the RTAS call which isolates the PCI slot > > > returns error 9001 "valid outstanding translations" and the removal of > > > the IO adapter fails. This is because when the PHBs are scanned, Linux > > > maps automatically the INTx interrupts in the Linux interrupt number > > > space but these are never removed. > > > > > > To solve this problem, we introduce a PPC platform specific > > > pcibios_remove_bus() routine which clears all interrupt mappings when > > > the bus is removed. This also clears the associated page table entries > > > of the ESB pages when using XIVE. > > > > > > For this purpose, we record the logical interrupt numbers of the > > > mapped interrupt under the PHB structure and let pcibios_remove_bus() > > > do the clean up. > > > > > > Since some PCI adapters, like GPUs, use the "interrupt-map" property > > > to describe interrupt mappings other than the legacy INTx interrupts, > > > we can not restrict the size of the mapping array to PCI_NUM_INTX. The > > > number of interrupt mappings is computed from the "interrupt-map" > > > property and the mapping array is allocated accordingly. > > > > > > Cc: "Oliver O'Halloran" > > > Cc: Alexey Kardashevskiy > > > Signed-off-by: Cédric Le Goater > > > > Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed > > to > > this patch. > > > > .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config > > OK. The patch is missing a NULL assignement after kfree() and that > might be the issue. > > I did try PHB removal under PowerNV, so I would like to understand > how we managed to remove twice the PCI bus and possibly reproduce. > Any chance we could grab what the syscall fuzzer (syzkaller) did ? Any update on this? Maybe Michael or Stephen could drop this for now, so our fuzzing could continue to find something else new? It can still be reproduced on today's linux-next. BTW, this is running trinity from an unprivileged user. This is the snapshot of the each fuzzing thread when this happens. http://people.redhat.com/qcai/pcibios_remove_bus/trinity-post-mortem.log It can be reproduced by simply keep running this for a while: $ trinity -C --arch 64 [19611.946827][T1717146] pci_bus 0035:03: busn_res: [bus 03-07] is released [19611.950956][T1717146] pci_bus 0035:08: busn_res: [bus 08-0c] is released [19611.951260][T1717146] = [19611.952336][T1717146] BUG kmalloc-16 (Tainted: GW O ): Object already free [19611.952365][T1717146] - [19611.952365][T1717146] [19611.952411][T1717146] Disabling lock debugging due to kernel taint [19611.952438][T1717146] INFO: Allocated in pcibios_scan_phb+0x104/0x3e0 age=1960714 cpu=4 pid=1 [19611.952481][T1717146]__slab_alloc+0xa4/0xf0 [19611.952500][T1717146]__kmalloc+0x294/0x330 [19611.952519][T1717146]pcibios_scan_phb+0x104/0x3e0 [19611.952549][T1717146]pcibios_init+0x84/0x124 [19611.952578][T1717146]do_one_initcall+0xac/0x528 [19611.952599][T1717146]kernel_init_freeable+0x35c/0x3fc [19611.952618][T1717146]kernel_init+0x24/0x148 [19611.952646][T1717146]ret_from_kernel_thread+0x5c/0x80 [19611.952665][T1717146] INFO: Freed in pcibios_remove_bus+0x70/0x90 age=0 cpu=16 pid=1717146 [19611.952691][T1717146]kfree+0x49c/0x510 [19611.952700][T1717146]pcibios_remove_bus+0x70/0x90 [19611.952711][T1717146]pci_remove_bus+0xe4/0x110 [19611.952730][T1717146]pci_remove_bus_device+0x74/0x170 [19611.952749][T1717146]pci_remove_bus_device+0x4c/0x170 [19611.952768][T1717146]pci_stop_and_remove_bus_device_locked+0x34/0x50 [19611.952798][T1717146]remove_store+0xc0/0xe0 [19611.952819][T1717146]dev_attr_store+0x30/0x50 [19611.952852][T1717146]sysfs_kf_write+0x68/0xb0 [19611.952870][T1717146]kernfs_fop_write+0x114/0x260 [19611.952904][T1717146]vfs_write+0xe4/0x260 [19611.952922][T1717146]ksys_write+0x74/0x130 [19611.952951][T1717146]system_call_exception+0xf8/0x1d0 [19611.952970][T1717146]system_call_common+0xe8/0x218 [19611.952990][T1717146] INFO: Slab 0x99caaf22 objects=178 used=174 fp=0x006a64b0 flags=0x7fff800201 [19611.953004][T1717146] INFO: Object 0xf360132d @offset=30192 fp=0x [19611.953004][T1717146] [19611.953048][T1717146] Redzone acef7298: bb bb bb bb bb bb bb bb bb bb bb
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 9/24/20 7:11 AM, Alexey Kardashevskiy wrote: > > > On 23/09/2020 17:06, Cédric Le Goater wrote: >> On 9/23/20 2:33 AM, Qian Cai wrote: >>> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: When a passthrough IO adapter is removed from a pseries machine using hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the guest OS to clear all page table entries related to the adapter. If some are still present, the RTAS call which isolates the PCI slot returns error 9001 "valid outstanding translations" and the removal of the IO adapter fails. This is because when the PHBs are scanned, Linux maps automatically the INTx interrupts in the Linux interrupt number space but these are never removed. To solve this problem, we introduce a PPC platform specific pcibios_remove_bus() routine which clears all interrupt mappings when the bus is removed. This also clears the associated page table entries of the ESB pages when using XIVE. For this purpose, we record the logical interrupt numbers of the mapped interrupt under the PHB structure and let pcibios_remove_bus() do the clean up. Since some PCI adapters, like GPUs, use the "interrupt-map" property to describe interrupt mappings other than the legacy INTx interrupts, we can not restrict the size of the mapping array to PCI_NUM_INTX. The number of interrupt mappings is computed from the "interrupt-map" property and the mapping array is allocated accordingly. Cc: "Oliver O'Halloran" Cc: Alexey Kardashevskiy Signed-off-by: Cédric Le Goater >>> >>> Some syscall fuzzing will trigger this on POWER9 NV where the traces >>> pointed to >>> this patch. >>> >>> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config >> >> OK. The patch is missing a NULL assignement after kfree() and that >> might be the issue. >> >> I did try PHB removal under PowerNV, so I would like to understand >> how we managed to remove twice the PCI bus and possibly reproduce. >> Any chance we could grab what the syscall fuzzer (syzkaller) did ? > > > > My guess would be it is doing this in parallel to provoke races. Concurrency removal and rescan should be controlled by : pci_stop_and_remove_bus_device_locked() pci_lock_rescan_remove() And, in the report, the stack traces are on the same CPU and PID. What I think is happening is that we did a couple of remove/rescan of the same PHB. The problem is that ->irq_map is not reallocated the second time because the PHB is re-scanned differently on the PowerNV platform. At the second remove, the ->irq_map being not NULL, we try to kfree it again and the allocator warns of a double free :/ This works fine on pseries/KVM because the PHB is never removed and on pseries/pHyp, pcibios_scan_phb() is called at PHB hotplug. But on PowerNV, pcibios_scan_phb() is only called at probe/boot time and not at hotplug time :/ I was a good thing to spot that before merge. But I need to revise that patch again. Thanks, C.
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 23/09/2020 17:06, Cédric Le Goater wrote: > On 9/23/20 2:33 AM, Qian Cai wrote: >> On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: >>> When a passthrough IO adapter is removed from a pseries machine using >>> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the >>> guest OS to clear all page table entries related to the adapter. If >>> some are still present, the RTAS call which isolates the PCI slot >>> returns error 9001 "valid outstanding translations" and the removal of >>> the IO adapter fails. This is because when the PHBs are scanned, Linux >>> maps automatically the INTx interrupts in the Linux interrupt number >>> space but these are never removed. >>> >>> To solve this problem, we introduce a PPC platform specific >>> pcibios_remove_bus() routine which clears all interrupt mappings when >>> the bus is removed. This also clears the associated page table entries >>> of the ESB pages when using XIVE. >>> >>> For this purpose, we record the logical interrupt numbers of the >>> mapped interrupt under the PHB structure and let pcibios_remove_bus() >>> do the clean up. >>> >>> Since some PCI adapters, like GPUs, use the "interrupt-map" property >>> to describe interrupt mappings other than the legacy INTx interrupts, >>> we can not restrict the size of the mapping array to PCI_NUM_INTX. The >>> number of interrupt mappings is computed from the "interrupt-map" >>> property and the mapping array is allocated accordingly. >>> >>> Cc: "Oliver O'Halloran" >>> Cc: Alexey Kardashevskiy >>> Signed-off-by: Cédric Le Goater >> >> Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed >> to >> this patch. >> >> .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config > > OK. The patch is missing a NULL assignement after kfree() and that > might be the issue. > > I did try PHB removal under PowerNV, so I would like to understand > how we managed to remove twice the PCI bus and possibly reproduce. > Any chance we could grab what the syscall fuzzer (syzkaller) did ? My guess would be it is doing this in parallel to provoke races. -- Alexey
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 9/23/20 2:33 AM, Qian Cai wrote: > On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: >> When a passthrough IO adapter is removed from a pseries machine using >> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the >> guest OS to clear all page table entries related to the adapter. If >> some are still present, the RTAS call which isolates the PCI slot >> returns error 9001 "valid outstanding translations" and the removal of >> the IO adapter fails. This is because when the PHBs are scanned, Linux >> maps automatically the INTx interrupts in the Linux interrupt number >> space but these are never removed. >> >> To solve this problem, we introduce a PPC platform specific >> pcibios_remove_bus() routine which clears all interrupt mappings when >> the bus is removed. This also clears the associated page table entries >> of the ESB pages when using XIVE. >> >> For this purpose, we record the logical interrupt numbers of the >> mapped interrupt under the PHB structure and let pcibios_remove_bus() >> do the clean up. >> >> Since some PCI adapters, like GPUs, use the "interrupt-map" property >> to describe interrupt mappings other than the legacy INTx interrupts, >> we can not restrict the size of the mapping array to PCI_NUM_INTX. The >> number of interrupt mappings is computed from the "interrupt-map" >> property and the mapping array is allocated accordingly. >> >> Cc: "Oliver O'Halloran" >> Cc: Alexey Kardashevskiy >> Signed-off-by: Cédric Le Goater > > Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed > to > this patch. > > .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config OK. The patch is missing a NULL assignement after kfree() and that might be the issue. I did try PHB removal under PowerNV, so I would like to understand how we managed to remove twice the PCI bus and possibly reproduce. Any chance we could grab what the syscall fuzzer (syzkaller) did ? Thanks, C. > > [ 3574.564109][ T965] ata1.00: disabled > [ 3574.580373][T151472] sd 0:0:0:0: [sdb] Synchronizing SCSI cache > [ 3574.581180][T151472] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: > Result: hostbyte=0x04 driverbyte=0x00 > [ 3574.581226][T151472] sd 0:0:0:0: [sdb] Stopping disk > [ 3574.581289][T151472] sd 0:0:0:0: [sdb] Start/Stop Unit failed: Result: > hostbyte=0x04 driverbyte=0x00 > [ 3574.611424][ T3019] Read-error on swap-device (254:1:849792) > [ 3574.611685][ T3019] Read-error on swap-device (254:1:914944) > [ 3574.611769][ T3019] Read-error on swap-device (254:1:915072) > [ 3574.611838][ T3019] Read-error on swap-device (254:1:915200) > [ 3574.611926][ T3019] Read-error on swap-device (254:1:915328) > [ 3574.612268][ T3084] Read-error on swap-device (254:1:792576) > [ 3574.612342][ T3084] Read-error on swap-device (254:1:792704) > [ 3574.612757][ T2362] Read-error on swap-device (254:1:957440) > [ 3574.612773][ T2905] Read-error on swap-device (254:1:784128) > [ 3574.613015][ T2362] Read-error on swap-device (254:1:957568) > [ 3574.613160][ T2905] Read-error on swap-device (254:1:784256) > [ 3574.613241][ T2362] Read-error on swap-device (254:1:957696) > [ 3574.613342][ T2362] Read-error on swap-device (254:1:957824) > [ 3574.614448][ T3019] Core dump to |/usr/lib/systemd/systemd-coredump pipe > failed > [ 3574.614663][ T3019] Read-error on swap-device (254:1:961536) > [ 3574.675330][T151844] Read-error on swap-device (254:1:128) > [ 3574.675515][T151844] Read-error on swap-device (254:1:256) > [ 3574.675700][T151844] Read-error on swap-device (254:1:384) > [ 3574.703570][ T971] ata2.00: disabled > [ 3574.710393][T151472] sd 1:0:0:0: [sda] Synchronizing SCSI cache > [ 3574.710864][T151472] sd 1:0:0:0: [sda] Synchronize Cache(10) failed: > Result: hostbyte=0x04 driverbyte=0x00 > [ 3574.710922][T151472] sd 1:0:0:0: [sda] Stopping disk > [ 3574.711010][T151472] sd 1:0:0:0: [sda] Start/Stop Unit failed: Result: > hostbyte=0x04 driverbyte=0x00 > [ 3574.826569][ T674] dm-0: writeback error on inode 68507862, offset 65536, > sector 54281504 > [ 3575.117547][ T3366] dm-0: writeback error on inode 68507851, offset 0, > sector 54378880 > [ 3575.140104][T151472] pci 0004:03:00.0: Removing from iommu group 3 > [ 3575.141778][T151472] pci 0004:03 : [PE# fb] Releasing PE > [ 3575.141965][T151472] pci 0004:03 : [PE# fb] Removing DMA window #0 > [ 3575.142452][T151472] pci 0004:03 : [PE# fb] Disabling 64-bit DMA bypass > [ 3575.149369][T151472] pci_bus 0004:03: busn_res: [bus 03] is released > [ 3575.150574][T152037] Read-error on swap-device (254:1:35584) > [ 3575.150713][T152037] Read-error on swap-device (254:1:35712) > [ 3575.152632][T152037] Read-error on swap-device (254:1:915584) > [ 3575.152706][T151472] pci_bus 0004:04: busn_res: [bus 04-08] is released > [ 3575.152983][T151472] > = > [ 3575.153937][T151472] BUG kmalloc-16 (Not tainted): Object
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote: > When a passthrough IO adapter is removed from a pseries machine using > hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the > guest OS to clear all page table entries related to the adapter. If > some are still present, the RTAS call which isolates the PCI slot > returns error 9001 "valid outstanding translations" and the removal of > the IO adapter fails. This is because when the PHBs are scanned, Linux > maps automatically the INTx interrupts in the Linux interrupt number > space but these are never removed. > > To solve this problem, we introduce a PPC platform specific > pcibios_remove_bus() routine which clears all interrupt mappings when > the bus is removed. This also clears the associated page table entries > of the ESB pages when using XIVE. > > For this purpose, we record the logical interrupt numbers of the > mapped interrupt under the PHB structure and let pcibios_remove_bus() > do the clean up. > > Since some PCI adapters, like GPUs, use the "interrupt-map" property > to describe interrupt mappings other than the legacy INTx interrupts, > we can not restrict the size of the mapping array to PCI_NUM_INTX. The > number of interrupt mappings is computed from the "interrupt-map" > property and the mapping array is allocated accordingly. > > Cc: "Oliver O'Halloran" > Cc: Alexey Kardashevskiy > Signed-off-by: Cédric Le Goater Some syscall fuzzing will trigger this on POWER9 NV where the traces pointed to this patch. .config: https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config [ 3574.564109][ T965] ata1.00: disabled [ 3574.580373][T151472] sd 0:0:0:0: [sdb] Synchronizing SCSI cache [ 3574.581180][T151472] sd 0:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 [ 3574.581226][T151472] sd 0:0:0:0: [sdb] Stopping disk [ 3574.581289][T151472] sd 0:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 [ 3574.611424][ T3019] Read-error on swap-device (254:1:849792) [ 3574.611685][ T3019] Read-error on swap-device (254:1:914944) [ 3574.611769][ T3019] Read-error on swap-device (254:1:915072) [ 3574.611838][ T3019] Read-error on swap-device (254:1:915200) [ 3574.611926][ T3019] Read-error on swap-device (254:1:915328) [ 3574.612268][ T3084] Read-error on swap-device (254:1:792576) [ 3574.612342][ T3084] Read-error on swap-device (254:1:792704) [ 3574.612757][ T2362] Read-error on swap-device (254:1:957440) [ 3574.612773][ T2905] Read-error on swap-device (254:1:784128) [ 3574.613015][ T2362] Read-error on swap-device (254:1:957568) [ 3574.613160][ T2905] Read-error on swap-device (254:1:784256) [ 3574.613241][ T2362] Read-error on swap-device (254:1:957696) [ 3574.613342][ T2362] Read-error on swap-device (254:1:957824) [ 3574.614448][ T3019] Core dump to |/usr/lib/systemd/systemd-coredump pipe failed [ 3574.614663][ T3019] Read-error on swap-device (254:1:961536) [ 3574.675330][T151844] Read-error on swap-device (254:1:128) [ 3574.675515][T151844] Read-error on swap-device (254:1:256) [ 3574.675700][T151844] Read-error on swap-device (254:1:384) [ 3574.703570][ T971] ata2.00: disabled [ 3574.710393][T151472] sd 1:0:0:0: [sda] Synchronizing SCSI cache [ 3574.710864][T151472] sd 1:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=0x00 [ 3574.710922][T151472] sd 1:0:0:0: [sda] Stopping disk [ 3574.711010][T151472] sd 1:0:0:0: [sda] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=0x00 [ 3574.826569][ T674] dm-0: writeback error on inode 68507862, offset 65536, sector 54281504 [ 3575.117547][ T3366] dm-0: writeback error on inode 68507851, offset 0, sector 54378880 [ 3575.140104][T151472] pci 0004:03:00.0: Removing from iommu group 3 [ 3575.141778][T151472] pci 0004:03 : [PE# fb] Releasing PE [ 3575.141965][T151472] pci 0004:03 : [PE# fb] Removing DMA window #0 [ 3575.142452][T151472] pci 0004:03 : [PE# fb] Disabling 64-bit DMA bypass [ 3575.149369][T151472] pci_bus 0004:03: busn_res: [bus 03] is released [ 3575.150574][T152037] Read-error on swap-device (254:1:35584) [ 3575.150713][T152037] Read-error on swap-device (254:1:35712) [ 3575.152632][T152037] Read-error on swap-device (254:1:915584) [ 3575.152706][T151472] pci_bus 0004:04: busn_res: [bus 04-08] is released [ 3575.152983][T151472] = [ 3575.153937][T151472] BUG kmalloc-16 (Not tainted): Object already free [ 3575.153962][T151472] - [ 3575.153962][T151472] [ 3575.154020][T151472] Disabling lock debugging due to kernel taint [ 3575.154047][T151472] INFO: Allocated in pcibios_scan_phb+0x104/0x3e0 age=356904 cpu=4 pid=1 [ 3575.154084][T151472] __slab_alloc+0xa4/0xf0 [ 3575.154105][T151472] __kmalloc+0x294/0x330 [ 3575.154127][T151472] pcibios_scan_phb+0x104/0x3e0 [
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On Fri, 7 Aug 2020 12:18:54 +0200, Cédric Le Goater wrote: > When a passthrough IO adapter is removed from a pseries machine using > hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the > guest OS to clear all page table entries related to the adapter. If > some are still present, the RTAS call which isolates the PCI slot > returns error 9001 "valid outstanding translations" and the removal of > the IO adapter fails. This is because when the PHBs are scanned, Linux > maps automatically the INTx interrupts in the Linux interrupt number > space but these are never removed. > > [...] Applied to powerpc/next. [1/1] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed https://git.kernel.org/powerpc/c/3a3181e16fbde752007759f8759d25e0ff1fc425 cheers
Re: [PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
On 07/08/2020 20:18, Cédric Le Goater wrote:
> When a passthrough IO adapter is removed from a pseries machine using
> hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
> guest OS to clear all page table entries related to the adapter. If
> some are still present, the RTAS call which isolates the PCI slot
> returns error 9001 "valid outstanding translations" and the removal of
> the IO adapter fails. This is because when the PHBs are scanned, Linux
> maps automatically the INTx interrupts in the Linux interrupt number
> space but these are never removed.
>
> To solve this problem, we introduce a PPC platform specific
> pcibios_remove_bus() routine which clears all interrupt mappings when
> the bus is removed. This also clears the associated page table entries
> of the ESB pages when using XIVE.
>
> For this purpose, we record the logical interrupt numbers of the
> mapped interrupt under the PHB structure and let pcibios_remove_bus()
> do the clean up.
>
> Since some PCI adapters, like GPUs, use the "interrupt-map" property
> to describe interrupt mappings other than the legacy INTx interrupts,
> we can not restrict the size of the mapping array to PCI_NUM_INTX. The
> number of interrupt mappings is computed from the "interrupt-map"
> property and the mapping array is allocated accordingly.
>
> Cc: "Oliver O'Halloran"
> Cc: Alexey Kardashevskiy
> Signed-off-by: Cédric Le Goater
I thought we could reuse some of the common OF code for the DT parsing
but we cannot (easily) so it is good as it is:
Reviewed-by: Alexey Kardashevskiy
> ---
>
> Changes since v2:
>
> - merged 2 patches.
>
> arch/powerpc/include/asm/pci-bridge.h | 6 ++
> arch/powerpc/kernel/pci-common.c | 114 ++
> 2 files changed, 120 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pci-bridge.h
> b/arch/powerpc/include/asm/pci-bridge.h
> index b92e81b256e5..ca75cf264ddf 100644
> --- a/arch/powerpc/include/asm/pci-bridge.h
> +++ b/arch/powerpc/include/asm/pci-bridge.h
> @@ -48,6 +48,9 @@ struct pci_controller_ops {
>
> /*
> * Structure of a PCI controller (host bridge)
> + *
> + * @irq_count: number of interrupt mappings
> + * @irq_map: interrupt mappings
> */
> struct pci_controller {
> struct pci_bus *bus;
> @@ -127,6 +130,9 @@ struct pci_controller {
>
> void *private_data;
> struct npu *npu;
> +
> + unsigned int irq_count;
> + unsigned int *irq_map;
> };
>
> /* These are used for config access before all the PCI probing
> diff --git a/arch/powerpc/kernel/pci-common.c
> b/arch/powerpc/kernel/pci-common.c
> index be108616a721..deb831f0ae13 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -353,6 +353,115 @@ struct pci_controller
> *pci_find_controller_for_domain(int domain_nr)
> return NULL;
> }
>
> +/*
> + * Assumption is made on the interrupt parent. All interrupt-map
> + * entries are considered to have the same parent.
> + */
> +static int pcibios_irq_map_count(struct pci_controller *phb)
> +{
> + const __be32 *imap;
> + int imaplen;
> + struct device_node *parent;
> + u32 intsize, addrsize, parintsize, paraddrsize;
> +
> + if (of_property_read_u32(phb->dn, "#interrupt-cells", ))
> + return 0;
> + if (of_property_read_u32(phb->dn, "#address-cells", ))
> + return 0;
> +
> + imap = of_get_property(phb->dn, "interrupt-map", );
> + if (!imap) {
> + pr_debug("%pOF : no interrupt-map\n", phb->dn);
> + return 0;
> + }
> + imaplen /= sizeof(u32);
> + pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
> +
> + if (imaplen < (addrsize + intsize + 1))
> + return 0;
> +
> + imap += intsize + addrsize;
> + parent = of_find_node_by_phandle(be32_to_cpup(imap));
> + if (!parent) {
> + pr_debug("%pOF : no imap parent found !\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#interrupt-cells", )) {
> + pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
> + return 0;
> + }
> +
> + if (of_property_read_u32(parent, "#address-cells", ))
> + paraddrsize = 0;
> +
> + return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
> +}
> +
> +static void pcibios_irq_map_init(struct pci_controller *phb)
> +{
> + phb->irq_count = pcibios_irq_map_count(phb);
> + if (phb->irq_count < PCI_NUM_INTX)
> + phb->irq_count = PCI_NUM_INTX;
> +
> + pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
> +
> + phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
> +GFP_KERNEL);
> +}
> +
> +static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
> +{
> + struct pci_controller *phb = pci_bus_to_host(pdev->bus);
> + int i;
> +
> + if (!phb->irq_map)
> +
[PATCH v2] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor expects the
guest OS to clear all page table entries related to the adapter. If
some are still present, the RTAS call which isolates the PCI slot
returns error 9001 "valid outstanding translations" and the removal of
the IO adapter fails. This is because when the PHBs are scanned, Linux
maps automatically the INTx interrupts in the Linux interrupt number
space but these are never removed.
To solve this problem, we introduce a PPC platform specific
pcibios_remove_bus() routine which clears all interrupt mappings when
the bus is removed. This also clears the associated page table entries
of the ESB pages when using XIVE.
For this purpose, we record the logical interrupt numbers of the
mapped interrupt under the PHB structure and let pcibios_remove_bus()
do the clean up.
Since some PCI adapters, like GPUs, use the "interrupt-map" property
to describe interrupt mappings other than the legacy INTx interrupts,
we can not restrict the size of the mapping array to PCI_NUM_INTX. The
number of interrupt mappings is computed from the "interrupt-map"
property and the mapping array is allocated accordingly.
Cc: "Oliver O'Halloran"
Cc: Alexey Kardashevskiy
Signed-off-by: Cédric Le Goater
---
Changes since v2:
- merged 2 patches.
arch/powerpc/include/asm/pci-bridge.h | 6 ++
arch/powerpc/kernel/pci-common.c | 114 ++
2 files changed, 120 insertions(+)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch/powerpc/include/asm/pci-bridge.h
index b92e81b256e5..ca75cf264ddf 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -48,6 +48,9 @@ struct pci_controller_ops {
/*
* Structure of a PCI controller (host bridge)
+ *
+ * @irq_count: number of interrupt mappings
+ * @irq_map: interrupt mappings
*/
struct pci_controller {
struct pci_bus *bus;
@@ -127,6 +130,9 @@ struct pci_controller {
void *private_data;
struct npu *npu;
+
+ unsigned int irq_count;
+ unsigned int *irq_map;
};
/* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..deb831f0ae13 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,115 @@ struct pci_controller *pci_find_controller_for_domain(int
domain_nr)
return NULL;
}
+/*
+ * Assumption is made on the interrupt parent. All interrupt-map
+ * entries are considered to have the same parent.
+ */
+static int pcibios_irq_map_count(struct pci_controller *phb)
+{
+ const __be32 *imap;
+ int imaplen;
+ struct device_node *parent;
+ u32 intsize, addrsize, parintsize, paraddrsize;
+
+ if (of_property_read_u32(phb->dn, "#interrupt-cells", ))
+ return 0;
+ if (of_property_read_u32(phb->dn, "#address-cells", ))
+ return 0;
+
+ imap = of_get_property(phb->dn, "interrupt-map", );
+ if (!imap) {
+ pr_debug("%pOF : no interrupt-map\n", phb->dn);
+ return 0;
+ }
+ imaplen /= sizeof(u32);
+ pr_debug("%pOF : imaplen=%d\n", phb->dn, imaplen);
+
+ if (imaplen < (addrsize + intsize + 1))
+ return 0;
+
+ imap += intsize + addrsize;
+ parent = of_find_node_by_phandle(be32_to_cpup(imap));
+ if (!parent) {
+ pr_debug("%pOF : no imap parent found !\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#interrupt-cells", )) {
+ pr_debug("%pOF : parent lacks #interrupt-cells!\n", phb->dn);
+ return 0;
+ }
+
+ if (of_property_read_u32(parent, "#address-cells", ))
+ paraddrsize = 0;
+
+ return imaplen / (addrsize + intsize + 1 + paraddrsize + parintsize);
+}
+
+static void pcibios_irq_map_init(struct pci_controller *phb)
+{
+ phb->irq_count = pcibios_irq_map_count(phb);
+ if (phb->irq_count < PCI_NUM_INTX)
+ phb->irq_count = PCI_NUM_INTX;
+
+ pr_debug("%pOF : interrupt map #%d\n", phb->dn, phb->irq_count);
+
+ phb->irq_map = kcalloc(phb->irq_count, sizeof(unsigned int),
+ GFP_KERNEL);
+}
+
+static void pci_irq_map_register(struct pci_dev *pdev, unsigned int virq)
+{
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ int i;
+
+ if (!phb->irq_map)
+ return;
+
+ for (i = 0; i < phb->irq_count; i++) {
+ /*
+* Look for an empty or an equivalent slot, as INTx
+* interrupts can be shared between adapters.
+*/
+ if (phb->irq_map[i] == virq || !phb->irq_map[i]) {
+ phb->irq_map[i] = virq;
+ break;
+
