[RFC PATCH V1 0/8] KASAN ppc64 support

[Benjamin Herrenschmidt]

On Mon, 2015-08-17 at 15:20 +0530, Aneesh Kumar K.V wrote:

> For kernel linear mapping, our address space looks like
> 0xc000000000000000 - 0xc0003fffffffffff  (64TB)
> 
> We can't have virtual address(effective address) above that range
> in 0xc region. Hence in-order to shadow the linear mapping, I am 
> using region 0xe. ie, the shadow mapping now looks liwe
> 
> 0xc000000000000000 -> 0xe000000000000000 

Why ? IE. Why can't you put the shadow at address +64T and have it work
for everything ?
.../...

> Another reason why inline instrumentation is difficult is that for
> inline instrumentation to work, we need to create a mapping for 
> _possible_
> virtual address space before kasan is fully initialized. ie, we need
> to create page table entries for the shadow of the entire 64TB range,
> with zero page, even though we have lesser ram. We definitely can't 
> bolt those entries. I am yet to get the shadow for kernel linear 
> mapping to work without bolting. Also we will have to get the page 
> table allocated for that, because we can't share page table entries. 
> Our fault path use pte entries for storing hash slot index.

Hrm, that means we might want to start considering a page table to
cover the linear mapping...

> If we are ok to steal part of that 64TB range, for kasan mapping , ie
> we make shadow of each region part of the same region, may be we can
> get inline instrumentation to work. But that still doesn't solve the
> page table allocation overhead issue mentioned above.
> 
> -aneesh