Overall, the approach here looks pretty sane. As you noted, it would be
nice to keep PAGE_OFFSET in one place, but it's not a deal breaker for
me. The use of the vmemmap code looks to be a nice fit.
Few nits below.
On 09/10/2014 07:31 AM, Andrey Ryabinin wrote:
> 16TB of virtual addressed used for shadow memory.
> It's located in range [0xffff800000000000 - 0xffff900000000000]
> Therefore PAGE_OFFSET has to be changed from 0xffff880000000000
> to 0xffff900000000000.
...
> It would be nice to not have different PAGE_OFFSET with and without CONFIG_KASAN.
> We have big enough hole between vmemmap and esp fixup stacks.
> So how about moving all direct mapping, vmalloc and vmemmap 8TB up without
> hiding it under CONFIG_KASAN?
Is there a reason this has to be _below_ the linear map? Couldn't we
just carve some space out of the vmalloc() area for the kasan area?
> arch/x86/Kconfig | 1 +
> arch/x86/boot/Makefile | 2 ++
> arch/x86/boot/compressed/Makefile | 2 ++
> arch/x86/include/asm/kasan.h | 20 ++++++++++++
> arch/x86/include/asm/page_64_types.h | 4 +++
> arch/x86/include/asm/pgtable.h | 7 ++++-
> arch/x86/kernel/Makefile | 2 ++
> arch/x86/kernel/dumpstack.c | 5 ++-
> arch/x86/kernel/head64.c | 6 ++++
> arch/x86/kernel/head_64.S | 16 ++++++++++
> arch/x86/mm/Makefile | 3 ++
> arch/x86/mm/init.c | 3 ++
> arch/x86/mm/kasan_init_64.c | 59 ++++++++++++++++++++++++++++++++++++
> arch/x86/realmode/Makefile | 2 +-
> arch/x86/realmode/rm/Makefile | 1 +
> arch/x86/vdso/Makefile | 1 +
> include/linux/kasan.h | 3 ++
> lib/Kconfig.kasan | 1 +
> 18 files changed, 135 insertions(+), 3 deletions(-)
> create mode 100644 arch/x86/include/asm/kasan.h
> create mode 100644 arch/x86/mm/kasan_init_64.c
This probably deserves an update of Documentation/x86/x86_64/mm.txt, too.
> +void __init kasan_map_shadow(void)
> +{
> + int i;
> +
> + memcpy(early_level4_pgt, init_level4_pgt, 4096);
> + load_cr3(early_level4_pgt);
> +
> + clear_zero_shadow_mapping(kasan_mem_to_shadow(PAGE_OFFSET),
> + kasan_mem_to_shadow(0xffffc80000000000UL));
This 0xffffc80000000000UL could be PAGE_OFFSET+MAXMEM.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>