From: "Aneesh Kumar K.V" <aneesh.kumar@linux•vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman•id.au>, linuxppc-dev@ozlabs•org
Cc: Michael Neuling <mikey@neuling•org>, cyrilbur@gmail•com
Subject: Re: [PATCH] powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash
Date: Fri, 24 Jul 2015 12:15:46 +0530 [thread overview]
Message-ID: <87si8eyrxh.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1437715135-5131-1-git-send-email-mpe@ellerman.id.au>
Michael Ellerman <mpe@ellerman•id.au> writes:
> The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
> PAGE_SIZE.
>
> However when built with a 4K PAGE_SIZE there is an additional config
> option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
> also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
>
> This is used in one obscure configuration, to support 64K pages for SPU
> local store on the Cell processor when the rest of the kernel is using
> 4K pages.
>
> In this configuration, pte_pagesize_index() is defined to just pass
> through its arguments to get_slice_psize(). However pte_pagesize_index()
> is called for both user and kernel addresses, whereas get_slice_psize()
> only knows how to handle user addresses.
>
> This has been broken forever, however until recently it happened to
> work. That was because in get_slice_psize() the large kernel address
> would cause the right shift of the slize mask to return zero.
>
> However in commit 7aa0727f3302 "powerpc/mm: Increase the slice range to
> 64TB", the get_slice_psize() code was changed so that instead of a right
> shift we do an array lookup based on the address. When passed a kernel
> address this means we index way off the end of the slice array and
> return random junk.
>
> That is only fatal if we happen to hit something non-zero, but when we
> do return a non-zero value we confuse the MMU code and eventually cause
> a check stop.
>
> This fix is ugly, but simple. When we're called for a kernel address we
> return 4K, which is always correct in this configuration, otherwise we
> use the slice mask.
>
> Fixes: 7aa0727f3302 ("powerpc/mm: Increase the slice range to 64TB")
> Reported-by: Cyril Bur <cyrilbur@gmail•com>
> Signed-off-by: Michael Ellerman <mpe@ellerman•id.au>
> ---
> arch/powerpc/include/asm/pgtable-ppc64.h | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
> index 3bb7488bd24b..330ae1d81662 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64.h
> @@ -135,7 +135,15 @@
> #define pte_iterate_hashed_end() } while(0)
>
> #ifdef CONFIG_PPC_HAS_HASH_64K
> -#define pte_pagesize_index(mm, addr, pte) get_slice_psize(mm, addr)
> +#define pte_pagesize_index(mm, addr, pte) \
> + ({ \
> + unsigned int psize; \
> + if (is_kernel_addr(addr)) \
> + psize = MMU_PAGE_4K; \
> + else \
> + psize = get_slice_psize(mm, addr); \
> + psize; \
> + })
> #else
> #define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
> #endif
That is confusing, because we enable PPC_HASH_HAS_64K for 64K page size
too. why not
psize = mmu_virtual_psize;
But that leave another question. What if kernel address used 16MB
mapping ? Or are we going to get a call for pte_pagesize_index, only for
vmalloc area of the kernel ? In any case, this need more comment
explaining the caller and possibly DEBUG_VM WARN_ON() to catch wrong
users ?
-aneesh
next prev parent reply other threads:[~2015-07-24 6:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-24 5:18 [PATCH] powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash Michael Ellerman
2015-07-24 6:45 ` Aneesh Kumar K.V [this message]
2015-07-25 8:59 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87si8eyrxh.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux$(echo .)vnet.ibm.com \
--cc=cyrilbur@gmail$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=mikey@neuling$(echo .)org \
--cc=mpe@ellerman$(echo .)id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox