From: Michael Ellerman <mpe@ellerman•id.au>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux•vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel•crashing.org>
Cc: linuxppc-dev@ozlabs•org, Michael Neuling <mikey@neuling•org>,
cyrilbur@gmail•com
Subject: Re: [PATCH] powerpc/mm: Fix pte_pagesize_index() crash on 4K w/64K hash
Date: Sat, 25 Jul 2015 18:59:30 +1000 [thread overview]
Message-ID: <1437814770.8513.2.camel@ellerman.id.au> (raw)
In-Reply-To: <87si8eyrxh.fsf@linux.vnet.ibm.com>
On Fri, 2015-07-24 at 12:15 +0530, Aneesh Kumar K.V wrote:
> 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.
...
> > 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.
We do, but in that case we get the definition in pte-hash64-64k.h which is:
#define pte_pagesize_index(mm, addr, pte) \
(((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
> why not
> psize = mmu_virtual_psize;
Maybe. Though I think actually mmu_io_psize would be correct. But none of the
other versions of the macro use the mmu_xx_psize variables they all use the
MMU_PAGE_xx #defines. So basically I just aped those.
Hopefully Ben can chime in, he wrote it originally.
> 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 ?
Not sure. I can't see any guarantee of that. I guess we don't map/unmap the
linear mapping, so possibly we're just getting away with it? And looks like
DEBUG_PAGEALLOC doesn't hit it.
> In any case, this need more comment explaining the caller and possibly
> DEBUG_VM WARN_ON() to catch wrong users ?
My plan is actually to drop support for 64K hash with 4K PAGE_SIZE as soon as
we've fixed this. I just didn't want to remove the code in a known broken state
when we knew how to fix it.
When we drop that support we'll just end up with two versions for 64K and 4K
respectively:
#define pte_pagesize_index(mm, addr, pte) \
(((pte) & _PAGE_COMBO)? MMU_PAGE_4K: MMU_PAGE_64K)
#define pte_pagesize_index(mm, addr, pte) MMU_PAGE_4K
And given it's only used in one function I'd be inclined to just open code it,
or at the very least move the macro into tlb_hash64.c
cheers
prev parent reply other threads:[~2015-07-25 8:59 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
2015-07-25 8:59 ` Michael Ellerman [this message]
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=1437814770.8513.2.camel@ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=aneesh.kumar@linux$(echo .)vnet.ibm.com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=cyrilbur@gmail$(echo .)com \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=mikey@neuling$(echo .)org \
/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