The !ATOMIC_IOMAP version of io_maping_init_wc will always return
success, even when the ioremap fails.
Since the ATOMIC_IOMAP version returns NULL when the init fails, and
callers check for a NULL return on error this is unexpected.
During a device probe, where the ioremap failed, a crash can look
like this:
BUG: unable to handle page fault for address: 0000000000210000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
Oops: 0002 [#1] PREEMPT SMP
CPU: 0 PID: 177 Comm:
RIP: 0010:fill_page_dma [i915]
gen8_ppgtt_create [i915]
i915_ppgtt_create [i915]
intel_gt_init [i915]
i915_gem_init [i915]
i915_driver_probe [i915]
pci_device_probe
really_probe
driver_probe_device
The remap failure occurred much earlier in the probe. If it had
been propagated, the driver would have exited with an error.
Return NULL on ioremap failure.
Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about
the io-mapping")
Cc: Andrew Morton <a...@linux-foundation.org>
Cc: Mike Rapoport <r...@linux.ibm.com>
Cc: Andy Shevchenko <andriy.shevche...@linux.intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: sta...@vger.kernel.org
Signed-off-by: Michael J. Ruhl <michael.j.r...@intel.com>
---
v2: reflect review comments
---
include/linux/io-mapping.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index 0beaa3eba155..5641e06cbcf7 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -118,7 +118,7 @@ io_mapping_init_wc(struct io_mapping *iomap,
iomap->prot = pgprot_noncached(PAGE_KERNEL);
#endif
- return iomap;
+ return iomap->iomem ? iomap : NULL;
}
static inline void
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
