Messages in this thread | | | Subject | Re: [PATCH] iommu/arm-smmu: Demote error messages to debug in shutdown callback | From | Robin Murphy <> | Date | Fri, 27 Mar 2020 19:02:58 +0000 |
| |
On 2020-03-27 3:09 pm, Sai Prakash Ranjan wrote: > Hi Robin, > > Thanks for taking a look at this. > > On 2020-03-27 19:42, Robin Murphy wrote: >> On 2020-03-27 1:28 pm, Sai Prakash Ranjan wrote: >>> Currently on reboot/shutdown, the following messages are >>> displayed on the console as error messages before the >>> system reboots/shutdown. >>> >>> On SC7180: >>> >>> arm-smmu 15000000.iommu: removing device with active domains! >>> arm-smmu 5040000.iommu: removing device with active domains! >>> >>> Demote the log level to debug since it does not offer much >>> help in identifying/fixing any issue as the system is anyways >>> going down and reduce spamming the kernel log. >> >> I've gone back and forth on this pretty much ever since we added the >> shutdown hook - on the other hand, if any devices *are* still running >> in those domains at this point, then once we turn off the SMMU and let >> those IOVAs go out on the bus as physical addresses, all manner of >> weirdness may ensue. Thus there is an argument for *some* indication >> that this may happen, although IMO it could be downgraded to at least >> dev_warn(). >> > > Any pointers to the weirdness here after SMMU is turned off? > Because if we look at the call sites, device_shutdown is called > from kernel_restart_prepare or kernel_shutdown_prepare which would > mean system is going down anyways, so do we really care about these > error messages or warnings from SMMU? > > arm_smmu_device_shutdown > platform_drv_shutdown > device_shutdown > kernel_restart_prepare > kernel_restart
Imagine your network driver doesn't implement a .shutdown method (so the hardware is still active regardless of device links), happens to have an Rx buffer or descriptor ring DMA-mapped at an IOVA that looks like the physical address of the memory containing some part of the kernel text lower down that call stack, and the MAC receives a broadcast IP packet at about the point arm_smmu_device_shutdown() is returning. Enjoy debugging that ;)
And if coincidental memory corruption seems too far-fetched for your liking, other fun alternatives might include "display tries to scan out from powered-off device, deadlocks interconnect and prevents anything else making progress", or "access to TZC-protected physical address triggers interrupt and over-eager Secure firmware resets system before orderly poweroff has a chance to finish".
Of course the fact that in practice we'll *always* see the warning because there's no way to tear down the default DMA domains, and even if all devices *have* been nicely quiesced there's no way to tell, is certainly less than ideal. Like I say, it's not entirely clear-cut either way...
Robin.
| |