Messages in this thread | | | Subject | Re: [PATCH/RFC] driver core: Postpone DMA tear-down until after devres release | From | John Garry <> | Date | Tue, 26 Mar 2019 17:36:42 +0000 |
| |
On 26/03/2019 12:31, Geert Uytterhoeven wrote: > Hi John, > > CC robh > > On Tue, Mar 26, 2019 at 12:42 PM John Garry <john.garry@huawei.com> wrote: >>> Memory is incorrectly freed using the direct ops, as dma_map_ops = NULL. >>> Oops... >>> >>> After reversing the order of the calls to arch_teardown_dma_ops() and >>> devres_release_all(), dma_map_ops is still valid, and the DMA memory is >>> now released using __iommu_free_attrs(): >>> >>> +sata_rcar ee300000.sata: dmam_release:32: size 2048 vaddr ffffff8012145000 dma_handle 0x0x00000000fffff000 attrs 0x0 >>> +sata_rcar ee300000.sata: dma_free_attrs:289: size 2048, ops = iommu_dma_ops >>> +sata_rcar ee300000.sata: dma_free_attrs:311: calling __iommu_free_attrs() >>> --- >>> drivers/base/dd.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c >>> index 8ac10af17c0043a3..d62487d024559620 100644 >>> --- a/drivers/base/dd.c >>> +++ b/drivers/base/dd.c >>> @@ -968,9 +968,9 @@ static void __device_release_driver(struct device *dev, struct device *parent) >>> drv->remove(dev); >>> >>> device_links_driver_cleanup(dev); >>> - arch_teardown_dma_ops(dev); >>> >>> devres_release_all(dev); >>> + arch_teardown_dma_ops(dev); >>> dev->driver = NULL; >> >> Hi guys, >> >> Could there still be the same problem in the error path of really_probe(): >> >> static int really_probe(struct device *dev, struct device_driver *drv) >> { >> >> [...] >> >> goto done; >> >> probe_failed: >> arch_teardown_dma_ops(dev); >> dma_failed: >> if (dev->bus) >> blocking_notifier_call_chain(&dev->bus->p->bus_notifier, >> BUS_NOTIFY_DRIVER_NOT_BOUND, dev); >> pinctrl_bind_failed: >> device_links_no_driver(dev); >> devres_release_all(dev); >> driver_sysfs_remove(dev); >> dev->driver = NULL; >> dev_set_drvdata(dev, NULL); >> >> We seem to be able to call arch_teardown_dma_ops() prior to >> devres_release_all() if we reach probe_failed label. > > Yes, this looks like another instance of the same problem. > And test_remove doesn't expose this, as it doesn't exercise the full cycle. >
Hi Geert,
OK, thanks.
There is another devres_release_all() call in device_release(). Not sure if there is another potential problem there also...
As for this issue, I'll look to fix unless anyone else doing it.
Cheers, John
> Gr{oetje,eeting}s, > > Geert >
| |