On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > Hi Will, > > I can go back to that approach, if Michal OK with it. But, that would > mean that I would need to touch every single architecture that > implements vmemmap_populate(), and also pass flags at least through > these functions on every architectures (some have more than one > decided by configs).: > > vmemmap_populate() > vmemmap_populate_basepages() > vmemmap_populate_hugepages() > vmemmap_pte_populate() > __vmemmap_alloc_block_buf() > alloc_block_buf() > vmemmap_alloc_block() > > IMO, while I understand that it looks strange that we must walk page > table after creating it, it is a better approach: more enclosed as it > effects kasan only, and more universal as it is in common code. While I understand that gfp mask approach might look better at first sight this is by no means a general purpose API so I would rather be pragmatic and have a smaller code footprint than a more general interface. Kasan is pretty much a special case and doing a one time initialization 2 pass thing is imho acceptable. If this turns out to be impractical in future then let's fix it up but right now I would rather go a simpler path. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
