]> git.baikalelectronics.ru Git - kernel.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)
commit3309ebc595eddd27953786d5118f71908130be39
treecb9260abb7df53262292715d865fe73e70624bbf
parent18d6a440cc2e5d3568c37cef39e559dbd61037ae
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
aeb072350021 ("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