Kernel 4.7: PAGE_GUARDED and _PAGE_NO_CACHE

[Michael Ellerman]

On Wed, 2016-06-08 at 12:33 +0100, Darren Stevens wrote:
> On 07/06/2016, Christian Zigotzky wrote:
> > 
> > 764041e0f43cc7846f6d8eb246d65b53cc06c764 is the first bad commit
> > commit 764041e0f43cc7846f6d8eb246d65b53cc06c764
> > Author: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
> > Date:   Fri Apr 29 23:26:09 2016 +1000
> > 
> >      powerpc/mm/radix: Add checks in slice code to catch radix usage
> > 
> 
> That's not where I ended up with my bisect, this commit is about 10 before the
> one I found to be bad, which is:
> 
> commit d6a9996e84ac4beb7713e9485f4563e100a9b03e
> Author: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
> Date:   Fri Apr 29 23:26:21 2016 +1000
> 
>     powerpc/mm: vmalloc abstraction in preparation for radix
>     
>     The vmalloc range differs between hash and radix config. Hence make
>     VMALLOC_START and related constants a variable which will be runtime
>     initialized depending on whether hash or radix mode is active.
>     
>     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar at linux.vnet.ibm.com>
>     [mpe: Fix missing init of ioremap_bot in pgtable_64.c for ppc64e]
>     Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
> 
> Not sure how we are getting different results though. I have attached my
> bisect log and the suspect commit, whcih is quite large. I'm not sure which
> part of it is at fault. I have some jobs to do now, but hope to get tesing
> this later today.

That one is more likely to be the problem, though I don't see anything glaringly
wrong with it.

Does your patch use any of the constants that are changed in that file? They now
aren't constants, they're initialised at boot, so if you use them too early
you'll get junk.

cheers