]> asedeno.scripts.mit.edu Git - linux.git/commit
powerpc/eeh: Handle hugepages in ioremap space
authorOliver O'Halloran <oohall@gmail.com>
Wed, 10 Jul 2019 15:05:17 +0000 (01:05 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Thu, 11 Jul 2019 15:02:09 +0000 (01:02 +1000)
commit33439620680be5225c1b8806579a291e0d761ca0
tree5fe6deef47c4b804058fb5f7a3a8a2c3f4285048
parent73a2b047c81046a7f734a5759ab5fdedbb6968fd
powerpc/eeh: Handle hugepages in ioremap space

In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
space") support for using hugepages in the vmalloc and ioremap areas was
enabled for radix. Unfortunately this broke EEH MMIO error checking.

Detection works by inserting a hook which checks the results of the
ioreadXX() set of functions.  When a read returns a 0xFFs response we
need to check for an error which we do by mapping the (virtual) MMIO
address back to a physical address, then mapping physical address to a
PCI device via an interval tree.

When translating virt -> phys we currently assume the ioremap space is
only populated by PAGE_SIZE mappings. If a hugepage mapping is found we
emit a WARN_ON(), but otherwise handles the check as though a normal
page was found. In pathalogical cases such as copying a buffer
containing a lot of 0xFFs from BAR memory this can result in the system
not booting because it's too busy printing WARN_ON()s.

There's no real reason to assume huge pages can't be present and we're
prefectly capable of handling them, so do that.

Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190710150517.27114-1-oohall@gmail.com
arch/powerpc/kernel/eeh.c