From b39ab98e2f4728d98973fd1bc531e3c4cbccb21c Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Mon, 30 Oct 2017 10:09:56 -0700 Subject: [PATCH] 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 77b246b32b2c ("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 Cc: Len Brown Cc: Tony Luck Cc: Fengguang Wu Cc: Tyler Baicar Cc: Will Deacon Signed-off-by: Linus Torvalds --- lib/ioremap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/ioremap.c b/lib/ioremap.c index 4bb30206b942..c835f9080c43 100644 --- a/lib/ioremap.c +++ b/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; -- GitLab