]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commit
Mark 'ioremap_page_range()' as possibly sleeping
authorLinus Torvalds <torvalds@linux-foundation.org>
Mon, 30 Oct 2017 17:09:56 +0000 (10:09 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Mon, 30 Oct 2017 17:09:56 +0000 (10:09 -0700)
commitb39ab98e2f4728d98973fd1bc531e3c4cbccb21c
treecb9260abb7df53262292715d865fe73e70624bbf
parentdaea3daaf9d5606735a722677125fe860f86ff41
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 <bp@suse.de>
Cc: Len Brown <lenb@kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Tyler Baicar <tbaicar@codeaurora.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
lib/ioremap.c