On Thu, Jul 10, 2014 at 02:12:19PM +0530, Madhusudanan Kandasamy wrote:
> V2 : Rewritten to avoid helper function as suggested by Stephen Rothwell.
> remap_4k_pfn() silently truncates upper bits of input 4K PFN if
> it cannot be contained in PTE. This leads invalid memory mapping
> and could result in a system crash when the memory is accessed.
> This patch fails remap_4k_pfn() and returns -EINVAL if the input
> 4K PFN cannot be contained in PTE.
>
> Signed-off-by: Madhusudanan Kandasamy <kma...@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/pte-hash64-64k.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/pte-hash64-64k.h
> b/arch/powerpc/include/asm/pte-hash64-64k.h
> index d836d94..b5178e4 100644
> --- a/arch/powerpc/include/asm/pte-hash64-64k.h
> +++ b/arch/powerpc/include/asm/pte-hash64-64k.h
> @@ -75,7 +75,8 @@
> (((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
>
> #define remap_4k_pfn(vma, addr, pfn, prot) \
> - remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
> + WARN_ON((pfn >= (1UL << (64 - PTE_RPN_SHIFT)))) ? -EINVAL : \
> + remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, \
> __pgprot(pgprot_val((prot)) | _PAGE_4K_PFN))
>
> #endif /* __ASSEMBLY__ */
> --
> 2.0.1
Chatted with Madhu. He'll send a new version that adds some
parentheses to protect 'pfn' inside the macro and the entire macro
against use cases like:
!remap_4k_pfn(...)
brian
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
