summaryrefslogtreecommitdiffstats
path: root/fs/jfs/super.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-10-30 10:09:56 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2017-10-30 10:09:56 -0700
commitb39ab98e2f4728d98973fd1bc531e3c4cbccb21c (patch)
treecb9260abb7df53262292715d865fe73e70624bbf /fs/jfs/super.c
parentdaea3daaf9d5606735a722677125fe860f86ff41 (diff)
downloadlinux-b39ab98e2f4728d98973fd1bc531e3c4cbccb21c.tar.bz2
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>
Diffstat (limited to 'fs/jfs/super.c')
0 files changed, 0 insertions, 0 deletions