Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 18-01-22, 19:50, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > > .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + > .../bindings/power/power-domain.yaml | 4 + Acked-by: Viresh Kumar -- viresh ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] dt-bindings: Improve phandle-array schemas
On 19/01/2022 02:50, Rob Herring wrote: > The 'phandle-array' type is a bit ambiguous. It can be either just an > array of phandles or an array of phandles plus args. Many schemas for > phandle-array properties aren't clear in the schema which case applies > though the description usually describes it. > > The array of phandles case boils down to needing: > > items: > maxItems: 1 > > The phandle plus args cases should typically take this form: > > items: > - items: > - description: A phandle > - description: 1st arg cell > - description: 2nd arg cell > > With this change, some examples need updating so that the bracketing of > property values matches the schema. > Samsung and memory controller bits look good: Acked-by: Krzysztof Kozlowski Best regards, Krzysztof ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v2] iommu/intel: Fix potential memory leak in intel_setup_irq_remapping
After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node
unconditionally allocated"). For tear down scenario, fn is only freed
after fail to allocate ir_domain, though it also should be freed in case
dmar_enable_qi returns error.
Besides free fn, irq_domain and ir_msi_domain need to be removed as well
if intel_setup_irq_remapping fails to enable queued invalidation.
Improve the rewinding path by add out_free_ir_domain and out_free_fwnode
lables per Baolu's suggestion.
Fixes: e3beca48a45b ("irqdomain/treewide: Keep firmware node unconditionally
allocated")
Suggested-by: Lu Baolu
Signed-off-by: Guoqing Jiang
---
v2: add remove irq_domains in the error handling path
drivers/iommu/intel/irq_remapping.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/intel/irq_remapping.c
b/drivers/iommu/intel/irq_remapping.c
index f912fe45bea2..a67319597884 100644
--- a/drivers/iommu/intel/irq_remapping.c
+++ b/drivers/iommu/intel/irq_remapping.c
@@ -569,9 +569,8 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu)
fn, &intel_ir_domain_ops,
iommu);
if (!iommu->ir_domain) {
- irq_domain_free_fwnode(fn);
pr_err("IR%d: failed to allocate irqdomain\n", iommu->seq_id);
- goto out_free_bitmap;
+ goto out_free_fwnode;
}
iommu->ir_msi_domain =
arch_create_remap_msi_irq_domain(iommu->ir_domain,
@@ -595,7 +594,7 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu)
if (dmar_enable_qi(iommu)) {
pr_err("Failed to enable queued invalidation\n");
- goto out_free_bitmap;
+ goto out_free_ir_domain;
}
}
@@ -619,6 +618,14 @@ static int intel_setup_irq_remapping(struct intel_iommu
*iommu)
return 0;
+out_free_ir_domain:
+ if (iommu->ir_msi_domain)
+ irq_domain_remove(iommu->ir_msi_domain);
+ iommu->ir_msi_domain = NULL;
+ irq_domain_remove(iommu->ir_domain);
+ iommu->ir_domain = NULL;
+out_free_fwnode:
+ irq_domain_free_fwnode(fn);
out_free_bitmap:
bitmap_free(bitmap);
out_free_pages:
--
2.31.1
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH] dt-bindings: Improve phandle-array schemas
The 'phandle-array' type is a bit ambiguous. It can be either just an array of phandles or an array of phandles plus args. Many schemas for phandle-array properties aren't clear in the schema which case applies though the description usually describes it. The array of phandles case boils down to needing: items: maxItems: 1 The phandle plus args cases should typically take this form: items: - items: - description: A phandle - description: 1st arg cell - description: 2nd arg cell With this change, some examples need updating so that the bracketing of property values matches the schema. Cc: Damien Le Moal Cc: Herbert Xu Cc: "David S. Miller" Cc: Chun-Kuang Hu Cc: Philipp Zabel Cc: Laurent Pinchart Cc: Kieran Bingham Cc: Vinod Koul Cc: Georgi Djakov Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Joerg Roedel Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Pavel Machek Cc: Mauro Carvalho Chehab Cc: Krzysztof Kozlowski Cc: Jakub Kicinski Cc: Wolfgang Grandegger Cc: Marc Kleine-Budde Cc: Andrew Lunn Cc: Vivien Didelot Cc: Florian Fainelli Cc: Vladimir Oltean Cc: Kalle Valo Cc: Viresh Kumar Cc: Stephen Boyd Cc: Kishon Vijay Abraham I Cc: Linus Walleij Cc: "Rafael J. Wysocki" Cc: Kevin Hilman Cc: Ulf Hansson Cc: Sebastian Reichel Cc: Mark Brown Cc: Mathieu Poirier Cc: Daniel Lezcano Cc: Zhang Rui Cc: Greg Kroah-Hartman Cc: Thierry Reding Cc: Jonathan Hunter Cc: Sudeep Holla Cc: Geert Uytterhoeven Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org Cc: dri-de...@lists.freedesktop.org Cc: dmaeng...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: iommu@lists.linux-foundation.org Cc: linux-l...@vger.kernel.org Cc: linux-me...@vger.kernel.org Cc: net...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-wirel...@vger.kernel.org Cc: linux-...@lists.infradead.org Cc: linux-g...@vger.kernel.org Cc: linux-ri...@lists.infradead.org Cc: linux-remotep...@vger.kernel.org Cc: alsa-de...@alsa-project.org Cc: linux-...@vger.kernel.org Signed-off-by: Rob Herring --- .../devicetree/bindings/arm/cpus.yaml | 2 + .../devicetree/bindings/arm/idle-states.yaml | 80 +-- .../devicetree/bindings/arm/pmu.yaml | 2 + .../bindings/ata/sata_highbank.yaml | 3 + .../bus/allwinner,sun50i-a64-de2.yaml | 5 +- .../bindings/crypto/intel,ixp4xx-crypto.yaml | 15 +++- .../allwinner,sun4i-a10-display-engine.yaml | 2 + .../display/mediatek/mediatek,hdmi.yaml | 5 +- .../devicetree/bindings/display/msm/gpu.yaml | 2 + .../bindings/display/renesas,du.yaml | 10 ++- .../display/rockchip/rockchip-drm.yaml| 2 + .../display/sprd/sprd,display-subsystem.yaml | 2 + .../bindings/display/ti/ti,am65x-dss.yaml | 3 +- .../devicetree/bindings/dma/dma-router.yaml | 2 + .../bindings/dma/st,stm32-dmamux.yaml | 2 +- .../bindings/dvfs/performance-domain.yaml | 1 - .../bindings/interconnect/qcom,rpmh.yaml | 2 + .../interrupt-controller/arm,gic-v3.yaml | 6 +- .../interrupt-controller/ti,sci-inta.yaml | 2 + .../bindings/iommu/mediatek,iommu.yaml| 6 +- .../bindings/iommu/renesas,ipmmu-vmsa.yaml| 6 ++ .../leds/backlight/led-backlight.yaml | 2 + .../allwinner,sun4i-a10-video-engine.yaml | 4 + .../bindings/media/nxp,imx8mq-mipi-csi2.yaml | 10 +-- .../devicetree/bindings/media/ti,cal.yaml | 4 + .../memory-controllers/mediatek,smi-larb.yaml | 2 +- .../samsung,exynos5422-dmc.yaml | 2 + .../net/allwinner,sun4i-a10-emac.yaml | 4 + .../bindings/net/can/bosch,c_can.yaml | 8 +- .../bindings/net/can/fsl,flexcan.yaml | 12 +-- .../devicetree/bindings/net/dsa/dsa-port.yaml | 2 + .../devicetree/bindings/net/fsl,fec.yaml | 8 +- .../bindings/net/intel,ixp4xx-ethernet.yaml | 15 +++- .../bindings/net/intel,ixp4xx-hss.yaml| 33 ++-- .../bindings/net/nxp,dwmac-imx.yaml | 4 + .../bindings/net/socionext,uniphier-ave4.yaml | 4 + .../devicetree/bindings/net/stm32-dwmac.yaml | 4 + .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 5 ++ .../bindings/net/wireless/mediatek,mt76.yaml | 4 + .../devicetree/bindings/opp/opp-v2-base.yaml | 2 + .../devicetree/bindings/perf/arm,dsu-pmu.yaml | 2 + .../bindings/phy/intel,combo-phy.yaml | 8 ++ .../devicetree/bindings/phy/ti,omap-usb2.yaml | 4 + .../pinctrl/aspeed,ast2500-pinctrl.yaml | 2 + .../bindings/pinctrl/canaan,k210-fpioa.yaml | 4 + .../pinctrl/mediatek,mt65xx-pinctrl.yaml | 2 + .../bindings/pinctrl/st,stm32-pinctrl.yaml| 10 ++- .../bindings/power/power-domain.yaml | 4 + .../bindings/power/renesas,apmu.yaml | 2 + .../power/rockchip,power-controller.yaml | 2 + .../bindings/power/supply/cw2015_battery.yaml | 6 +- .../bindings/power/supply/power-supply.yaml | 2 + .../bindings/regulator/regulator.yaml | 2 + .../bindings/regulato
iommu/amd: bug report: page table memory leak
Hi,
I've hit a memory leak while testing qemu v6.2.0-rc4 on an AMD EPYC 7J13
(Milan) system. Starting an almost 1T guest, the leak is over 1.5G per
qemu invocation. I haven't checked whether the leak is proportional to
guest size. It happens with a vfio device, and only when the guest's
memory is preallocated using qemu prealloc (this latter part is kinda
strange). It happens when the guest memory uses THP but not hugetlb.
Bisection:
# bad: [df0cc57e057f18e44dac8e6c18aba47ab53202f9] Linux 5.16
# good: [f40ddce88593482919761f74910f42f4b84c004b] Linux 5.11
git bisect start 'df0cc57e057f1' 'f40ddce885934' '--' 'drivers/vfio'
'drivers/iommu' 'include/linux/amd-iommu.h' 'include/linux/dma-iommu.h'
'include/linux/intel-iommu.h' 'include/linux/iommu-helper.h'
'include/linux/of_iommu.h' 'include/
linux/omap-iommu.h' 'include/linux/platform_data/iommu-omap.h'
'include/linux/iommu.h' 'include/trace/events/intel_iommu.h'
'include/trace/events/iommu.h' 'include/uapi/linux/iommu.h'
'include/uapi/linux/virtio_iommu.h' 'arch/x86/events/a
md/iommu.h' 'arch/x86/events/amd/iommu.c' 'arch/x86/include/asm/iommu.h'
'arch/x86/include/asm/iommu_table.h' 'arch/x86/kernel/pci-iommu_table.c'
# bad: [cee57d4fe74e82e784f6566bad3e3bb1ca51a211] iommu/vt-d: Remove
unnecessary braces
git bisect bad cee57d4fe74e82e784f6566bad3e3bb1ca51a211
# bad: [9fb5fad562fa0a41c84691714d99c23f54168a9e] iommu: remove
DOMAIN_ATTR_PAGING
git bisect bad 9fb5fad562fa0a41c84691714d99c23f54168a9e
# bad: [45e606f2726926b04094e1c9bf809bca4884c57f] Merge branches 'arm/renesas',
'arm/smmu', 'x86/amd', 'x86/vt-d' and 'core' into next
git bisect bad 45e606f2726926b04094e1c9bf809bca4884c57f
# good: [7060377ce06f9cd3ed6274c0f2310463feb5baec] Merge branch 'for-joerg/mtk'
into for-joerg/arm-smmu/updates
git bisect good 7060377ce06f9cd3ed6274c0f2310463feb5baec
# bad: [6778ff5b21bd8e78c8bd547fd66437cf2657fd9b] iommu/amd: Fix performance
counter initialization
git bisect bad 6778ff5b21bd8e78c8bd547fd66437cf2657fd9b
# good: [f9b4df790aa4372bfa11b7d212e537b763295429] iommu/amd: Declare functions
as extern
git bisect good f9b4df790aa4372bfa11b7d212e537b763295429
# bad: [33aef9786046d9a5744cd1e8d5d0ce800d611fdc] iommu/amd: Rename variables
to be consistent with struct io_pgtable_ops
git bisect bad 33aef9786046d9a5744cd1e8d5d0ce800d611fdc
# bad: [e42ba0633064ef23eb1c8c21edf96bac1541bd4b] iommu/amd: Restructure code
for freeing page table
git bisect bad e42ba0633064ef23eb1c8c21edf96bac1541bd4b
# good: [18954252a1d0b12e1b77087b55c37fb43b09e12a] iommu/amd: Move IO page
table related functions
git bisect good 18954252a1d0b12e1b77087b55c37fb43b09e12a
# first bad commit: [e42ba0633064ef23eb1c8c21edf96bac1541bd4b] iommu/amd:
Restructure code for freeing page table
commit e42ba0633064ef23eb1c8c21edf96bac1541bd4b
Author: Suravee Suthikulpanit
Date: Tue Dec 15 01:36:59 2020 -0600
iommu/amd: Restructure code for freeing page table
By consolidate logic into v1_free_pgtable helper function,
which is called from IO page table framework.
Signed-off-by: Suravee Suthikulpanit
Link:
https://lore.kernel.org/r/20201215073705.123786-8-suravee.suthikulpa...@amd.com
Signed-off-by: Joerg Roedel
drivers/iommu/amd/amd_iommu.h | 1 -
drivers/iommu/amd/io_pgtable.c | 41 -
drivers/iommu/amd/iommu.c | 21 -
3 files changed, 28 insertions(+), 35 deletions(-)
Qemu command line:
numactl -m 1 -N 1 "$QEMU" \
-name vmol74 \
-machine q35,accel=kvm,usb=off,dump-guest-core=off,memory-backend=pc.ram \
-cpu host,host-phys-bits=true \
-smp cpus=32 \
-no-user-config \
-nodefaults \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-boot strict=on \
-drive file=${vm_image},format=raw,if=none,id=drive-ide0-0-0 \
-device
ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=2 \
-device vfio-pci,host=${pci_addr},id=net2,bus=pcie.0 \
-msg timestamp=on \
-nographic \
-object
memory-backend-ram,id=pc.ram,size=980g,prealloc=on,prealloc-threads=16 -m 980g \
-daemonize
Kernel config attached, and I can provide other details too if I left
anything out.
thanks,
Daniel
amd-leak-config.gz
Descrip
Re: nvme: IO_PAGE_FAULT logged with Intel SSDPEKKF512G8
Dear Keith, Thank you for your quick response. Am 18.01.22 um 17:53 schrieb Keith Busch: On Tue, Jan 18, 2022 at 03:32:45PM +0100, Paul Menzel wrote: On a Dell OptiPlex 5055 with an Intel SSDPEKKF512G8, Linux 5.10.82 reported an IO_PAGE_FAULT error. This is the first and only time this has happened. $ dmesg --level=err [4.194306] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000c address=0xc080 flags=0x0050] [4.206970] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000c address=0xc000 flags=0x0050] [7.327820] kfd kfd: VERDE not supported in kfd $ lspci -nn -s 01:00.0 01:00.0 Non-Volatile memory controller [0108]: Intel Corporation SSD Pro 7600p/760p/E 6100p Series [8086:f1a6] (rev 03) I think it's a bug with the iommu implementation. That would surprise me, but I am adding Jörg and Suravee to the recipient list. Last time, I saw an IO_PAGE_FAULT, it was a bug in the amdgpu driver. If it causes problems, you can typically work around it with kernel parameter "iommu=soft". I have not noticed any problems yet. Kind regards, Paul PS: No idea, if useful, but I include the content of `/proc/iomem`: $ sudo more /proc/iomem -0fff : Reserved 1000-00087fff : System RAM 00088000-00088fff : Reserved 00089000-0009efff : System RAM 0009f000-000b : Reserved 000a-000b : PCI Bus :00 000c-000c3fff : PCI Bus :00 000c4000-000c7fff : PCI Bus :00 000c8000-000cbfff : PCI Bus :00 000cc000-000c : PCI Bus :00 000d-000d3fff : PCI Bus :00 000d4000-000d7fff : PCI Bus :00 000d8000-000dbfff : PCI Bus :00 000dc000-000d : PCI Bus :00 000e-000e3fff : PCI Bus :00 000e4000-000e7fff : PCI Bus :00 000e8000-000ebfff : PCI Bus :00 000ec000-000e : PCI Bus :00 000f-000f : System ROM 0010-09cf : System RAM 0500-05e03316 : Kernel code 0600-063a8fff : Kernel rodata 0640-06762eff : Kernel data 06d31000-06ff : Kernel bss 09d0-09e6 : Reserved 09e7-7afb5fff : System RAM 7afb6000-7afb6fff : Reserved 7afb7000-7afbbfff : System RAM 7afbc000-7afbcfff : Reserved 7afbd000-dadbefff : System RAM dadbf000-dafbefff : Unknown E820 type dafbf000-dcfbefff : Reserved dcfbf000-defbefff : ACPI Non-volatile Storage defbf000-deffefff : ACPI Tables defff000-deff : System RAM df00-dfff : Reserved e000-f7ff : PCI Bus :00 e000-efff : PCI Bus :06 e000-efff : :06:00.0 f000-f00f : PCI Bus :02 f000-f00f : PCI Bus :03 f000-f00f : PCI Bus :04 f000-f000 : :04:00.0 f000-f000 : tg3 f001-f001 : :04:00.0 f001-f001 : tg3 f002-f002 : :04:00.0 f002-f002 : tg3 f010-f01f : PCI Bus :08 f010-f0107fff : :08:00.3 f010-f0107fff : ICH HD audio f0108000-f0108fff : :08:00.2 f0108000-f0108fff : ahci f020-f04f : PCI Bus :07 f020-f02f : :07:00.3 f020-f02f : xhci-hcd f030-f03f : :07:00.2 f040-f0401fff : :07:00.2 f050-f05f : PCI Bus :06 f050-f053 : :06:00.0 f054-f0543fff : :06:00.1 f054-f0543fff : ICH HD audio f056-f057 : :06:00.0 f060-f06f : PCI Bus :02 f060-f061 : :02:00.1 f060-f061 : ahci f062-f0627fff : :02:00.0 f062-f0627fff : xhci-hcd f068-f06f : :02:00.1 f070-f07f : PCI Bus :01 f070-f0703fff : :01:00.0 f070-f0703fff : nvme f800-fbff : PCI MMCONFIG [bus 00-3f] f800-fbff : Reserved fc00-feaf : PCI Bus :00 fc00-fc07 : amd_iommu fdf0-fdff : pnp 00:00 fec0-fec00fff : Reserved fec0-fec003ff : IOAPIC 0 fec01000-fec013ff : IOAPIC 1 fec1-fec10fff : Reserved fec3-fec30fff : AMDIF030:00 fed0-fed003ff : HPET 0 fed0-fed003ff : PNP0103:00 fed4-fed44fff : MSFT0101:00 fed8-fed80fff : Reserved fed81500-fed818ff : AMDI0030:00 fee0-fee00fff : Local APIC fee0-fee00fff : pnp 00:00 ff00- : Reserved ff00- : pnp 00:03 1-81eff : System RAM 81f00-81fff : RAM buffer ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: nvme: IO_PAGE_FAULT logged with Intel SSDPEKKF512G8
On Tue, Jan 18, 2022 at 03:32:45PM +0100, Paul Menzel wrote: > On a Dell OptiPlex 5055 with an Intel SSDPEKKF512G8, Linux 5.10.82 reported > an IO_PAGE_FAULT error. This is the first and only time this has happened. > > $ dmesg --level=err > [4.194306] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT > domain=0x000c address=0xc080 flags=0x0050] > [4.206970] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT > domain=0x000c address=0xc000 flags=0x0050] > [7.327820] kfd kfd: VERDE not supported in kfd > $ lspci -nn -s 01:00.0 > 01:00.0 Non-Volatile memory controller [0108]: Intel Corporation SSD Pro > 7600p/760p/E 6100p Series [8086:f1a6] (rev 03) I think it's a bug with the iommu implementation. If it causes problems, you can typically work around it with kernel parameter "iommu=soft". ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3] iommu: Fix potential use-after-free during probe
On 1/18/2022 7:19 PM, Robin Murphy wrote:
> On 2022-01-12 13:13, Vijayanand Jitta wrote:
>> Kasan has reported the following use after free on dev->iommu.
>> when a device probe fails and it is in process of freeing dev->iommu
>> in dev_iommu_free function, a deferred_probe_work_func runs in parallel
>> and tries to access dev->iommu->fwspec in of_iommu_configure path thus
>> causing use after free.
>>
>> BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4
>> Read of size 8 at addr ff87a2f1acb8 by task kworker/u16:2/153
>>
>> Workqueue: events_unbound deferred_probe_work_func
>> Call trace:
>> dump_backtrace+0x0/0x33c
>> show_stack+0x18/0x24
>> dump_stack_lvl+0x16c/0x1e0
>> print_address_description+0x84/0x39c
>> __kasan_report+0x184/0x308
>> kasan_report+0x50/0x78
>> __asan_load8+0xc0/0xc4
>> of_iommu_configure+0xb4/0x4a4
>> of_dma_configure_id+0x2fc/0x4d4
>> platform_dma_configure+0x40/0x5c
>> really_probe+0x1b4/0xb74
>> driver_probe_device+0x11c/0x228
>> __device_attach_driver+0x14c/0x304
>> bus_for_each_drv+0x124/0x1b0
>> __device_attach+0x25c/0x334
>> device_initial_probe+0x24/0x34
>> bus_probe_device+0x78/0x134
>> deferred_probe_work_func+0x130/0x1a8
>> process_one_work+0x4c8/0x970
>> worker_thread+0x5c8/0xaec
>> kthread+0x1f8/0x220
>> ret_from_fork+0x10/0x18
>>
>> Allocated by task 1:
>> kasan_kmalloc+0xd4/0x114
>> __kasan_kmalloc+0x10/0x1c
>> kmem_cache_alloc_trace+0xe4/0x3d4
>> __iommu_probe_device+0x90/0x394
>> probe_iommu_group+0x70/0x9c
>> bus_for_each_dev+0x11c/0x19c
>> bus_iommu_probe+0xb8/0x7d4
>> bus_set_iommu+0xcc/0x13c
>> arm_smmu_bus_init+0x44/0x130 [arm_smmu]
>> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
>> platform_drv_probe+0xe4/0x13c
>> really_probe+0x2c8/0xb74
>> driver_probe_device+0x11c/0x228
>> device_driver_attach+0xf0/0x16c
>> __driver_attach+0x80/0x320
>> bus_for_each_dev+0x11c/0x19c
>> driver_attach+0x38/0x48
>> bus_add_driver+0x1dc/0x3a4
>> driver_register+0x18c/0x244
>> __platform_driver_register+0x88/0x9c
>> init_module+0x64/0xff4 [arm_smmu]
>> do_one_initcall+0x17c/0x2f0
>> do_init_module+0xe8/0x378
>> load_module+0x3f80/0x4a40
>> __se_sys_finit_module+0x1a0/0x1e4
>> __arm64_sys_finit_module+0x44/0x58
>> el0_svc_common+0x100/0x264
>> do_el0_svc+0x38/0xa4
>> el0_svc+0x20/0x30
>> el0_sync_handler+0x68/0xac
>> el0_sync+0x160/0x180
>>
>> Freed by task 1:
>> kasan_set_track+0x4c/0x84
>> kasan_set_free_info+0x28/0x4c
>> kasan_slab_free+0x120/0x15c
>> __kasan_slab_free+0x18/0x28
>> slab_free_freelist_hook+0x204/0x2fc
>> kfree+0xfc/0x3a4
>> __iommu_probe_device+0x284/0x394
>> probe_iommu_group+0x70/0x9c
>> bus_for_each_dev+0x11c/0x19c
>> bus_iommu_probe+0xb8/0x7d4
>> bus_set_iommu+0xcc/0x13c
>> arm_smmu_bus_init+0x44/0x130 [arm_smmu]
>> arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
>> platform_drv_probe+0xe4/0x13c
>> really_probe+0x2c8/0xb74
>> driver_probe_device+0x11c/0x228
>> device_driver_attach+0xf0/0x16c
>> __driver_attach+0x80/0x320
>> bus_for_each_dev+0x11c/0x19c
>> driver_attach+0x38/0x48
>> bus_add_driver+0x1dc/0x3a4
>> driver_register+0x18c/0x244
>> __platform_driver_register+0x88/0x9c
>> init_module+0x64/0xff4 [arm_smmu]
>> do_one_initcall+0x17c/0x2f0
>> do_init_module+0xe8/0x378
>> load_module+0x3f80/0x4a40
>> __se_sys_finit_module+0x1a0/0x1e4
>> __arm64_sys_finit_module+0x44/0x58
>> el0_svc_common+0x100/0x264
>> do_el0_svc+0x38/0xa4
>> el0_svc+0x20/0x30
>> el0_sync_handler+0x68/0xac
>> el0_sync+0x160/0x180
>>
>> Fix this by taking device_lock during probe_iommu_group.
>>
>> Signed-off-by: Vijayanand Jitta
>> ---
>> drivers/iommu/iommu.c | 12
>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>> index dd7863e..261792d 100644
>> --- a/drivers/iommu/iommu.c
>> +++ b/drivers/iommu/iommu.c
>> @@ -1617,7 +1617,7 @@ static int probe_iommu_group(struct device *dev,
>> void *data)
>> {
>> struct list_head *group_list = data;
>> struct iommu_group *group;
>> - int ret;
>> + int ret = 0;
>> /* Device is probed already if in a group */
>> group = iommu_group_get(dev);
>> @@ -1626,9 +1626,13 @@ static int probe_iommu_group(struct device
>> *dev, void *data)
>> return 0;
>> }
>> - ret = __iommu_probe_device(dev, group_list);
>> - if (ret == -ENODEV)
>> - ret = 0;
>> + ret = device_trylock(dev);
>> + if (ret) {
>
> This doesn't seem right - we can't have a non-deterministic situation
> where __iommu_probe_device() may or may not be called depending on what
> anyone else might be doing with the device at the same time.
>
> I don't fully understand how __iommu_probe_device() and
> of_iommu_configure() can be running for the same device at the same
> time, but if that's not a race which can be fixed in its own right, then
Thanks for the
nvme: IO_PAGE_FAULT logged with Intel SSDPEKKF512G8
Dear Linux folks, On a Dell OptiPlex 5055 with an Intel SSDPEKKF512G8, Linux 5.10.82 reported an IO_PAGE_FAULT error. This is the first and only time this has happened. $ dmesg --level=err [4.194306] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000c address=0xc080 flags=0x0050] [4.206970] nvme :01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000c address=0xc000 flags=0x0050] [7.327820] kfd kfd: VERDE not supported in kfd $ lspci -nn -s 01:00.0 01:00.0 Non-Volatile memory controller [0108]: Intel Corporation SSD Pro 7600p/760p/E 6100p Series [8086:f1a6] (rev 03) $ sudo ./nvme list Node SN Model Namespace Usage Format FW Rev - - -- nvme0n1 BTHH82250YQK512D SSDPEKKF512G8 NVMe INTEL 512GB 1 512.11 GB / 512.11 GB512 B + 0 B D03N Please find the output of `dmesg` attached. Kind regards, Paul PS: Some more info: $ lspci -tvn -[:00]-+-00.0 1022:1450 +-00.2 1022:1451 +-01.0 1022:1452 +-01.1-[01]00.0 8086:f1a6 +-01.3-[02-05]--+-00.0 1022:43bb | +-00.1 1022:43b7 | \-00.2-[03-05]--+-00.0-[04]00.0 14e4:1687 | \-01.0-[05]-- +-02.0 1022:1452 +-03.0 1022:1452 +-03.1-[06]--+-00.0 1002:682b |\-00.1 1002:aab0 +-04.0 1022:1452 +-07.0 1022:1452 +-07.1-[07]--+-00.0 1022:145a |+-00.2 1022:1456 |\-00.3 1022:145c +-08.0 1022:1452 +-08.1-[08]--+-00.0 1022:1455 |+-00.2 1022:7901 |\-00.3 1022:1457 +-14.0 1022:790b +-14.3 1022:790e +-18.0 1022:1460 +-18.1 1022:1461 +-18.2 1022:1462 +-18.3 1022:1463 +-18.4 1022:1464 +-18.5 1022:1465 +-18.6 1022:1466 \-18.7 1022:1467[0.00] Linux version 5.10.82.mx64.414 (r...@invidia.molgen.mpg.de) (gcc (GCC) 7.5.0, GNU ld (GNU Binutils) 2.37) #1 SMP Mon Nov 29 14:15:19 CET 2021 [0.00] Command line: BOOT_IMAGE=/boot/bzImage.x86_64 root=LABEL=root ro crashkernel=64G-:256M console=ttyS0,115200n8 console=tty0 init=/bin/systemd audit=0 random.trust_cpu=on [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00087fff] usable [0.00] BIOS-e820: [mem 0x00088000-0x00088fff] reserved [0.00] BIOS-e820: [mem 0x00089000-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x000b] reserved [0.00] BIOS-e820: [mem 0x0010-0x09cf] usable [0.00] BIOS-e820: [mem 0x09d0-0x09e6] reserved [0.00] BIOS-e820: [mem 0x09e7-0x7afb5fff] usable [0.00] BIOS-e820: [mem 0x7afb6000-0x7afb6fff] reserved [0.00] BIOS-e820: [mem 0x7afb7000-0x7afbbfff] usable [0.00] BIOS-e820: [mem 0x7afbc000-0x7afbcfff] reserved [0.00] BIOS-e820: [mem 0x7afbd000-0xdadbefff] usable [0.00] BIOS-e820: [mem 0xdadbf000-0xdafbefff] type 20 [0.00] BIOS-e820: [mem 0xdafbf000-0xdcfbefff] reserved [0.00] BIOS-e820: [mem 0xdcfbf000-0xdefbefff] ACPI NVS [0.00] BIOS-e820: [mem 0xdefbf000-0xdeffefff] ACPI data [0.00] BIOS-e820: [mem 0xdefff000-0xdeff] usable [0.00] BIOS-e820: [mem 0xdf00-0xdfff] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed80fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e8
Re: [PATCH v3] iommu: Fix potential use-after-free during probe
On 2022-01-12 13:13, Vijayanand Jitta wrote:
Kasan has reported the following use after free on dev->iommu.
when a device probe fails and it is in process of freeing dev->iommu
in dev_iommu_free function, a deferred_probe_work_func runs in parallel
and tries to access dev->iommu->fwspec in of_iommu_configure path thus
causing use after free.
BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4
Read of size 8 at addr ff87a2f1acb8 by task kworker/u16:2/153
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace+0x0/0x33c
show_stack+0x18/0x24
dump_stack_lvl+0x16c/0x1e0
print_address_description+0x84/0x39c
__kasan_report+0x184/0x308
kasan_report+0x50/0x78
__asan_load8+0xc0/0xc4
of_iommu_configure+0xb4/0x4a4
of_dma_configure_id+0x2fc/0x4d4
platform_dma_configure+0x40/0x5c
really_probe+0x1b4/0xb74
driver_probe_device+0x11c/0x228
__device_attach_driver+0x14c/0x304
bus_for_each_drv+0x124/0x1b0
__device_attach+0x25c/0x334
device_initial_probe+0x24/0x34
bus_probe_device+0x78/0x134
deferred_probe_work_func+0x130/0x1a8
process_one_work+0x4c8/0x970
worker_thread+0x5c8/0xaec
kthread+0x1f8/0x220
ret_from_fork+0x10/0x18
Allocated by task 1:
kasan_kmalloc+0xd4/0x114
__kasan_kmalloc+0x10/0x1c
kmem_cache_alloc_trace+0xe4/0x3d4
__iommu_probe_device+0x90/0x394
probe_iommu_group+0x70/0x9c
bus_for_each_dev+0x11c/0x19c
bus_iommu_probe+0xb8/0x7d4
bus_set_iommu+0xcc/0x13c
arm_smmu_bus_init+0x44/0x130 [arm_smmu]
arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
platform_drv_probe+0xe4/0x13c
really_probe+0x2c8/0xb74
driver_probe_device+0x11c/0x228
device_driver_attach+0xf0/0x16c
__driver_attach+0x80/0x320
bus_for_each_dev+0x11c/0x19c
driver_attach+0x38/0x48
bus_add_driver+0x1dc/0x3a4
driver_register+0x18c/0x244
__platform_driver_register+0x88/0x9c
init_module+0x64/0xff4 [arm_smmu]
do_one_initcall+0x17c/0x2f0
do_init_module+0xe8/0x378
load_module+0x3f80/0x4a40
__se_sys_finit_module+0x1a0/0x1e4
__arm64_sys_finit_module+0x44/0x58
el0_svc_common+0x100/0x264
do_el0_svc+0x38/0xa4
el0_svc+0x20/0x30
el0_sync_handler+0x68/0xac
el0_sync+0x160/0x180
Freed by task 1:
kasan_set_track+0x4c/0x84
kasan_set_free_info+0x28/0x4c
kasan_slab_free+0x120/0x15c
__kasan_slab_free+0x18/0x28
slab_free_freelist_hook+0x204/0x2fc
kfree+0xfc/0x3a4
__iommu_probe_device+0x284/0x394
probe_iommu_group+0x70/0x9c
bus_for_each_dev+0x11c/0x19c
bus_iommu_probe+0xb8/0x7d4
bus_set_iommu+0xcc/0x13c
arm_smmu_bus_init+0x44/0x130 [arm_smmu]
arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]
platform_drv_probe+0xe4/0x13c
really_probe+0x2c8/0xb74
driver_probe_device+0x11c/0x228
device_driver_attach+0xf0/0x16c
__driver_attach+0x80/0x320
bus_for_each_dev+0x11c/0x19c
driver_attach+0x38/0x48
bus_add_driver+0x1dc/0x3a4
driver_register+0x18c/0x244
__platform_driver_register+0x88/0x9c
init_module+0x64/0xff4 [arm_smmu]
do_one_initcall+0x17c/0x2f0
do_init_module+0xe8/0x378
load_module+0x3f80/0x4a40
__se_sys_finit_module+0x1a0/0x1e4
__arm64_sys_finit_module+0x44/0x58
el0_svc_common+0x100/0x264
do_el0_svc+0x38/0xa4
el0_svc+0x20/0x30
el0_sync_handler+0x68/0xac
el0_sync+0x160/0x180
Fix this by taking device_lock during probe_iommu_group.
Signed-off-by: Vijayanand Jitta
---
drivers/iommu/iommu.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index dd7863e..261792d 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1617,7 +1617,7 @@ static int probe_iommu_group(struct device *dev, void
*data)
{
struct list_head *group_list = data;
struct iommu_group *group;
- int ret;
+ int ret = 0;
/* Device is probed already if in a group */
group = iommu_group_get(dev);
@@ -1626,9 +1626,13 @@ static int probe_iommu_group(struct device *dev, void
*data)
return 0;
}
- ret = __iommu_probe_device(dev, group_list);
- if (ret == -ENODEV)
- ret = 0;
+ ret = device_trylock(dev);
+ if (ret) {
This doesn't seem right - we can't have a non-deterministic situation
where __iommu_probe_device() may or may not be called depending on what
anyone else might be doing with the device at the same time.
I don't fully understand how __iommu_probe_device() and
of_iommu_configure() can be running for the same device at the same
time, but if that's not a race which can be fixed in its own right, then
I think adding a refcount to dev_iommu would be a more sensible way to
mitigate it.
Robin.
+ ret = __iommu_probe_device(dev, group_list);
+ if (ret == -ENODEV)
+ ret = 0;
+ device_unlock(dev);
+ }
return ret;
}
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfounda
