[PATCH v4 07/12] mm: enable lazy_mmu sections to nest

[David Hildenbrand (Red Hat)]

> So without in_lazy_mmu_mode() check above the arch-specific set_pte()
> implementation enters a wrong branch, which ends up in:
> 
> [  394.503134] Call Trace:
> [  394.503137]  [<00007fffe01333f4>] dump_stack_lvl+0xbc/0xf0
> [  394.503143]  [<00007fffe010298c>] vpanic+0x1cc/0x418
> [  394.503149]  [<00007fffe0102c7a>] panic+0xa2/0xa8
> [  394.503154]  [<00007fffe01e7a8a>] check_panic_on_warn+0x8a/0xb0
> [  394.503160]  [<00007fffe082d122>] end_report+0x72/0x110
> [  394.503166]  [<00007fffe082d3e6>] kasan_report+0xc6/0x100
> [  394.503171]  [<00007fffe01b9556>] ipte_batch_ptep_get+0x146/0x150
> [  394.503176]  [<00007fffe0830096>] kasan_populate_vmalloc_pte+0xe6/0x1e0
> [  394.503183]  [<00007fffe0718050>] apply_to_pte_range+0x1a0/0x570
> [  394.503189]  [<00007fffe07260fa>] __apply_to_page_range+0x3ca/0x8f0
> [  394.503195]  [<00007fffe0726648>] apply_to_page_range+0x28/0x40
> [  394.503201]  [<00007fffe082fe34>] __kasan_populate_vmalloc+0x324/0x340
> [  394.503207]  [<00007fffe076954e>] alloc_vmap_area+0x31e/0xbf0
> [  394.503213]  [<00007fffe0770106>] __get_vm_area_node+0x1a6/0x2d0
> [  394.503218]  [<00007fffe07716fa>] __vmalloc_node_range_noprof+0xba/0x260
> [  394.503224]  [<00007fffe0771970>] __vmalloc_node_noprof+0xd0/0x110
> [  394.503229]  [<00007fffe0771a22>] vmalloc_noprof+0x32/0x40
> [  394.503234]  [<00007fff604eaa42>] full_fit_alloc_test+0xb2/0x3e0 [test_vmalloc]
> [  394.503241]  [<00007fff604eb478>] test_func+0x488/0x760 [test_vmalloc]
> [  394.503247]  [<00007fffe025ad68>] kthread+0x368/0x630
> [  394.503253]  [<00007fffe01391e0>] __ret_from_fork+0xd0/0x490
> [  394.503259]  [<00007fffe24e468a>] ret_from_fork+0xa/0x30
> 
> I could have cached lazy_mmu_state::active as arch-specific data
> and check it, but then what is the point to have it generalized?

Do you mean we should set ->active before calling into the arch 
callback? We could do that I think.