Mark 'ioremap_page_range()' as possibly sleeping

It turns out that some drivers seem to think it's ok to remap page
ranges from within interrupts and even NMI's.  That is definitely not
the case, since the page table build-up is simply not interrupt-safe.

This showed up in the zero-day robot that reported it for the ACPI APEI
GHES ("Generic Hardware Error Source") driver.  Normally it had been
hidden by the fact that no page table operations had been needed because
the vmalloc area had been set up by other things.

Apparently due to a recent change to the GHEI driver: commit
77b246b ("acpi: apei: check for pending errors when probing GHES
entries") 0day actually caught a case during bootup whenthe ioremap
called down to page allocation.  But that recent change only showed the
symptom, it wasn't the root cause of the problem.

Hopefully it is limited to just that one driver.

If you need to access random physical memory, you either need to ioremap
in process context, or you need to use the FIXMAP facility to set one
particular fixmap entry to the required mapping - that can be done safely.

Cc: Borislav Petkov <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Tony Luck <[email protected]>
Cc: Fengguang Wu <[email protected]>
Cc: Tyler Baicar <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

lib/ioremap.c

@@ -161,6 +161,7 @@ int ioremap_page_range(unsigned long addr,
 	unsigned long next;
 	int err;
 
+	might_sleep();
 	BUG_ON(addr >= end);
 
 	start = addr;