summaryrefslogtreecommitdiff
path: root/tools
diff options
context:
space:
mode:
authorMichael Ellerman <mpe@ellerman.id.au>2017-05-18 13:37:31 +0300
committerMichael Ellerman <mpe@ellerman.id.au>2017-05-19 06:04:35 +0300
commite41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 (patch)
tree6dcc62e4b1497d5d890c095b13166138e08fa6fb /tools
parentbfb9956ab4d8242f4594b5f4bee534b935384fd9 (diff)
downloadlinux-e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34.tar.xz
powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash
virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on an address. What this means in practice is that it should only return true for addresses in the linear mapping which are backed by a valid PFN. We are failing to properly check that the address is in the linear mapping, because virt_to_pfn() will return a valid looking PFN for more or less any address. That bug is actually caused by __pa(), used in virt_to_pfn(). eg: __pa(0xc000000000010000) = 0x10000 # Good __pa(0xd000000000010000) = 0x10000 # Bad! __pa(0x0000000000010000) = 0x10000 # Bad! This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give you something bogus back. Until we can verify if that GCC bug is no longer an issue, or come up with another solution, this commit does the minimal fix to make virt_addr_valid() work, by explicitly checking that the address is in the linear mapping region. Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by: Paul Mackerras <paulus@ozlabs.org> Reviewed-by: Balbir Singh <bsingharora@gmail.com> Tested-by: Breno Leitao <breno.leitao@gmail.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions