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 akpm@linux-foundation.org Cc: Mike Rapoport rppt@linux.ibm.com Cc: Andy Shevchenko andriy.shevchenko@linux.intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: stable@vger.kernel.org Signed-off-by: Michael J. Ruhl michael.j.ruhl@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