Messages in this thread | | | Subject | Re: [PATCH v2 6/9] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" | From | John Garry <> | Date | Fri, 8 Nov 2019 17:49:13 +0000 |
| |
On 08/11/2019 17:32, Will Deacon wrote: > On Fri, Nov 08, 2019 at 05:25:09PM +0000, John Garry wrote: >> On 08/11/2019 16:47, Will Deacon wrote: >>> On Fri, Nov 08, 2019 at 04:44:25PM +0000, John Garry wrote: >>>> BTW, it now looks like it was your v1 series I was testing there, on your >>>> branch iommu/module. It would be helpful to update for ease of testing. >>> >>> Yes, sorry about that. I'll update it now (although I'm not sure it will >>> help with this -- I was going to see what happens with other devices such >>> as the intel-iommu or storage controllers) >> >> So I tried your v2 series for this - it has the same issue, as I >> anticipated. > > Right, I'm just not sure how resilient drivers are expected to be to force > unbinding like this. You can break lots of stuff with root...
For sure, but it is good practice to limit that.
I had to fix something like this recently, so know about it... another potential problem is use-after-frees, where your device managed memory is freed at removal but still registered somewhere.
> >> It seems that some iommu drivers do call iommu_device_register(), so maybe a >> decent reference. Or simply stop the driver being unbound. > > I'm not sure what you mean about iommu_device_register() (we call that > already),
Sorry, I meant to say iommu_device_unregister().
but I guess we can keep the '.suppress_bind_attrs = true' if > necessary.
It may be good to add it to older stable kernels also, pre c07b6426df92.
I'll have a play on my laptop and see how well that works if > you start unbinding stuff.
Cheers, John
| |