At 2021-01-10 05:26:08, "Linus Walleij" wrote: >On Sat, Jan 9, 2021 at 5:51 AM Hailong liu wrote: > >> From: Hailong Liu >> >> The size of kasan_early_shadow_pte[] now is PTRS_PER_PTE which defined to >> 512 for arm architecture. This means that it only covers the prev Linux pte >> entries, but not the HWTABLE pte entries for arm. >> >> The reason it works well current is that the symbol kasan_early_shadow_page >> immediately following kasan_early_shadow_pte in memory is page aligned, >> which makes kasan_early_shadow_pte look like a 4KB size array. But we can't >> ensure the order always right with different compiler/linker, nor more bss >> symbols be introduced. >> >> We had a test with QEMU + vexpress：put a 512KB-size symbol with attribute >> __section(".bss..page_aligned") after kasan_early_shadow_pte, and poison it >> after kasan_early_init(). Then enabled CONFIG_KASAN, it failed to boot up. >> >> Signed-off-by: Hailong Liu >> Signed-off-by: Ziliang Guo > >OK I see the problem, I think. > >> +#ifndef PTE_HWTABLE_PTRS >> +#define PTE_HWTABLE_PTRS 0 >> +#endif > >Can this even happen? We have either pgtable-2level.h or >pgtable-3level.h, both of which define PTE_HWTABLE_PTRS. > I guess not for arm. But I'm not sure for other ARCHs. >> extern unsigned char kasan_early_shadow_page[PAGE_SIZE]; >> -extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE]; >> +extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS]; > >Yeah this looks exactly like bm_pte so it makes sense. > Yes, it comes from prototype of pm_pte. And it does solve the problems our project encountered and seems to work well for now. >If you drop the first ifndef, >Reviewed-by: Linus Walleij > >Yours, >Linus Walleij Thanks.