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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
