]>
Commit | Line | Data |
---|---|---|
6ebfa1bb GKH |
1 | From 376991db4b6464e906d699ef07681e2ffa8ab08c Mon Sep 17 00:00:00 2001 |
2 | From: Geert Uytterhoeven <geert+renesas@glider.be> | |
3 | Date: Thu, 7 Feb 2019 20:36:53 +0100 | |
4 | Subject: driver core: Postpone DMA tear-down until after devres release | |
5 | MIME-Version: 1.0 | |
6 | Content-Type: text/plain; charset=UTF-8 | |
7 | Content-Transfer-Encoding: 8bit | |
8 | ||
9 | From: Geert Uytterhoeven <geert+renesas@glider.be> | |
10 | ||
11 | commit 376991db4b6464e906d699ef07681e2ffa8ab08c upstream. | |
12 | ||
13 | When unbinding the (IOMMU-enabled) R-Car SATA device on Salvator-XS | |
14 | (R-Car H3 ES2.0), in preparation of rebinding against vfio-platform for | |
15 | device pass-through for virtualization: | |
16 | ||
17 | echo ee300000.sata > /sys/bus/platform/drivers/sata_rcar/unbind | |
18 | ||
19 | the kernel crashes with: | |
20 | ||
21 | Unable to handle kernel paging request at virtual address ffffffbf029ffffc | |
22 | Mem abort info: | |
23 | ESR = 0x96000006 | |
24 | Exception class = DABT (current EL), IL = 32 bits | |
25 | SET = 0, FnV = 0 | |
26 | EA = 0, S1PTW = 0 | |
27 | Data abort info: | |
28 | ISV = 0, ISS = 0x00000006 | |
29 | CM = 0, WnR = 0 | |
30 | swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000007e8c586c | |
31 | [ffffffbf029ffffc] pgd=000000073bfc6003, pud=000000073bfc6003, pmd=0000000000000000 | |
32 | Internal error: Oops: 96000006 [#1] SMP | |
33 | Modules linked in: | |
34 | CPU: 0 PID: 1098 Comm: bash Not tainted 5.0.0-rc5-salvator-x-00452-g37596f884f4318ef #287 | |
35 | Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT) | |
36 | pstate: 60400005 (nZCv daif +PAN -UAO) | |
37 | pc : __free_pages+0x8/0x58 | |
38 | lr : __dma_direct_free_pages+0x50/0x5c | |
39 | sp : ffffff801268baa0 | |
40 | x29: ffffff801268baa0 x28: 0000000000000000 | |
41 | x27: ffffffc6f9c60bf0 x26: ffffffc6f9c60bf0 | |
42 | x25: ffffffc6f9c60810 x24: 0000000000000000 | |
43 | x23: 00000000fffff000 x22: ffffff8012145000 | |
44 | x21: 0000000000000800 x20: ffffffbf029fffc8 | |
45 | x19: 0000000000000000 x18: ffffffc6f86c42c8 | |
46 | x17: 0000000000000000 x16: 0000000000000070 | |
47 | x15: 0000000000000003 x14: 0000000000000000 | |
48 | x13: ffffff801103d7f8 x12: 0000000000000028 | |
49 | x11: ffffff8011117604 x10: 0000000000009ad8 | |
50 | x9 : ffffff80110126d0 x8 : ffffffc6f7563000 | |
51 | x7 : 6b6b6b6b6b6b6b6b x6 : 0000000000000018 | |
52 | x5 : ffffff8011cf3cc8 x4 : 0000000000004000 | |
53 | x3 : 0000000000080000 x2 : 0000000000000001 | |
54 | x1 : 0000000000000000 x0 : ffffffbf029fffc8 | |
55 | Process bash (pid: 1098, stack limit = 0x00000000c38e3e32) | |
56 | Call trace: | |
57 | __free_pages+0x8/0x58 | |
58 | __dma_direct_free_pages+0x50/0x5c | |
59 | arch_dma_free+0x1c/0x98 | |
60 | dma_direct_free+0x14/0x24 | |
61 | dma_free_attrs+0x9c/0xdc | |
62 | dmam_release+0x18/0x20 | |
63 | release_nodes+0x25c/0x28c | |
64 | devres_release_all+0x48/0x4c | |
65 | device_release_driver_internal+0x184/0x1f0 | |
66 | device_release_driver+0x14/0x1c | |
67 | unbind_store+0x70/0xb8 | |
68 | drv_attr_store+0x24/0x34 | |
69 | sysfs_kf_write+0x4c/0x64 | |
70 | kernfs_fop_write+0x154/0x1c4 | |
71 | __vfs_write+0x34/0x164 | |
72 | vfs_write+0xb4/0x16c | |
73 | ksys_write+0x5c/0xbc | |
74 | __arm64_sys_write+0x14/0x1c | |
75 | el0_svc_common+0x98/0x114 | |
76 | el0_svc_handler+0x1c/0x24 | |
77 | el0_svc+0x8/0xc | |
78 | Code: d51b4234 17fffffa a9bf7bfd 910003fd (b9403404) | |
79 | ---[ end trace 8c564cdd3a1a840f ]--- | |
80 | ||
81 | While I've bisected this to commit e8e683ae9a736407 ("iommu/of: Fix | |
82 | probe-deferral"), and reverting that commit on post-v5.0-rc4 kernels | |
83 | does fix the problem, this turned out to be a red herring. | |
84 | ||
85 | On arm64, arch_teardown_dma_ops() resets dev->dma_ops to NULL. | |
86 | Hence if a driver has used a managed DMA allocation API, the allocated | |
87 | DMA memory will be freed using the direct DMA ops, while it may have | |
88 | been allocated using a custom DMA ops (iommu_dma_ops in this case). | |
89 | ||
90 | Fix this by reversing the order of the calls to devres_release_all() and | |
91 | arch_teardown_dma_ops(). | |
92 | ||
93 | Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> | |
94 | Acked-by: Christoph Hellwig <hch@lst.de> | |
95 | Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> | |
96 | Cc: stable <stable@vger.kernel.org> | |
97 | Reviewed-by: Robin Murphy <robin.murphy@arm.com> | |
98 | [rm: backport for 4.12-4.19 - kernels before 5.0 will not see | |
99 | the crash above, but may get silent memory corruption instead] | |
100 | Signed-off-by: Robin Murphy <robin.murphy@arm.com> | |
101 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
102 | ||
103 | --- | |
104 | drivers/base/dd.c | 2 +- | |
105 | 1 file changed, 1 insertion(+), 1 deletion(-) | |
106 | ||
107 | --- a/drivers/base/dd.c | |
108 | +++ b/drivers/base/dd.c | |
109 | @@ -963,9 +963,9 @@ static void __device_release_driver(stru | |
110 | drv->remove(dev); | |
111 | ||
112 | device_links_driver_cleanup(dev); | |
113 | - dma_deconfigure(dev); | |
114 | ||
115 | devres_release_all(dev); | |
116 | + dma_deconfigure(dev); | |
117 | dev->driver = NULL; | |
118 | dev_set_drvdata(dev, NULL); | |
119 | if (dev->pm_domain && dev->pm_domain->dismiss) |