Thread (27 messages) 27 messages, 3 authors, 2015-08-18

Re: [RFC PATCH V1 0/8] KASAN ppc64 support

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2015-08-17 10:01:39

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help