** Description changed: + [Impact] + + The ipmmu-vmsa driver registers itself to the system via an initcall() + to ipmmu_init(), and in case it's the first (or the only) iommu driver, + it registers its iommu ops to the platform bus - in the tegra2 case, + there's no iommu hardware, so all drivers bail out, except for the + ipmmu-vmsa. + + Later on, during boot, when the Tegra host1x is probing + (drivers/gpu/host1x/dev.c::host1x_probe()), it checks if an iommu device + is present (drivers/iommu/iommu.c::iommu_present() that does so by + identifying if any iommu ops were registered) and attach to the + supposedly present device, incurring in a null pointer dereference. + + Upstream quickly acknowledged the problem, and rolled a patch to + restrict the ipmmu-vmsa driver to register if and only if a compatible + device is present. + + The fix appared initially in 4.19, and was later backported via stable + to 4.18.x, and this is a clean cherry pick of that commit. + + [Fix] + + Apply the attached patch and recompile. + + [How to test] + + Try to boot a patched kernel on a Tegra2 board. + + [Regession potential] + + None, the fix is trivial. + + -- + + Original bug: + Hi, booting the bionic kernel (4.15.0-29-generic) on my Tegra20 device (no iommu), I found it crashes during display driver setup. The bootlog (and crash) is attached. Asking on Tegra IRC channel, digetx found that this is caused by the IPMMU-VMSA driver which is always registered via initcall. Adding "initcall_blacklist=ipmmu_init" to the kernel parameters makes it boot fine. Maybe this buggy driver should be disabled in the config (or fixed somehow)?
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1783746 Title: ipmmu is always registered Status in linux package in Ubuntu: Confirmed Bug description: [Impact] The ipmmu-vmsa driver registers itself to the system via an initcall() to ipmmu_init(), and in case it's the first (or the only) iommu driver, it registers its iommu ops to the platform bus - in the tegra2 case, there's no iommu hardware, so all drivers bail out, except for the ipmmu-vmsa. Later on, during boot, when the Tegra host1x is probing (drivers/gpu/host1x/dev.c::host1x_probe()), it checks if an iommu device is present (drivers/iommu/iommu.c::iommu_present() that does so by identifying if any iommu ops were registered) and attach to the supposedly present device, incurring in a null pointer dereference. Upstream quickly acknowledged the problem, and rolled a patch to restrict the ipmmu-vmsa driver to register if and only if a compatible device is present. The fix appared initially in 4.19, and was later backported via stable to 4.18.x, and this is a clean cherry pick of that commit. [Fix] Apply the attached patch and recompile. [How to test] Try to boot a patched kernel on a Tegra2 board. [Regession potential] None, the fix is trivial. -- Original bug: Hi, booting the bionic kernel (4.15.0-29-generic) on my Tegra20 device (no iommu), I found it crashes during display driver setup. The bootlog (and crash) is attached. Asking on Tegra IRC channel, digetx found that this is caused by the IPMMU-VMSA driver which is always registered via initcall. Adding "initcall_blacklist=ipmmu_init" to the kernel parameters makes it boot fine. Maybe this buggy driver should be disabled in the config (or fixed somehow)? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1783746/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
