Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Pavel Tatashin
>> I guess we could implement that on arm64 using our current vmemmap_populate >> logic and an explicit memset. Hi Will, I will send out a new patch series with x86/arm64 versions of kasan_map_populate(), so you could take a look if this is something that is acceptable. Thank you, Pavel

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Pavel Tatashin
> > Ok, but I'm still missing why you think that is needed. What would be the > second page table walker that needs implementing? > > I guess we could implement that on arm64 using our current vmemmap_populate > logic and an explicit memset. > Hi Will, What do you mean by explicit memset()? We ca

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Will Deacon
Hi Pavel, On Mon, Oct 09, 2017 at 02:59:09PM -0400, Pavel Tatashin wrote: > > We have two table walks even with your patch series applied afaict: one in > > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > > in the core code. > > I meant to say implementing two new page tab

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Pavel Tatashin
Hi Will, > We have two table walks even with your patch series applied afaict: one in > our definition of vmemmap_populate (arch/arm64/mm/mmu.c) and this one > in the core code. I meant to say implementing two new page table walkers, not at runtime. > My worry is that these are actually highly a

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Will Deacon
On Mon, Oct 09, 2017 at 02:42:32PM -0400, Pavel Tatashin wrote: > Hi Will, > > In addition to what Michal wrote: > > > As an interim step, why not introduce something like > > vmemmap_alloc_block_flags and make the page-table walking opt-out for > > architectures that don't want it? Then we can j

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Will Deacon
On Mon, Oct 09, 2017 at 08:14:33PM +0200, Michal Hocko wrote: > On Mon 09-10-17 13:51:47, Pavel Tatashin wrote: > > 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 pa

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Pavel Tatashin
Hi Will, In addition to what Michal wrote: > As an interim step, why not introduce something like > vmemmap_alloc_block_flags and make the page-table walking opt-out for > architectures that don't want it? Then we can just pass __GFP_ZERO from > our vmemmap_populate where necessary and other arch

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Will Deacon
Hi Pavel, On Mon, Oct 09, 2017 at 01:51:47PM -0400, Pavel Tatashin wrote: > 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

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Michal Hocko
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 arc

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Pavel Tatashin
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).: v

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-09 Thread Will Deacon
On Tue, Oct 03, 2017 at 03:48:46PM +0100, Mark Rutland wrote: > On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > > During early boot, kasan uses vmemmap_populate() to establish its shadow > > memory. But, that interface is intended for struct pages use. > > > > Because of the curr

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-03 Thread Pasha Tatashin
Hi Mark, I considered using a new *populate() function for shadow without using vmemmap_populate(), but that makes things unnecessary complicated: vmemmap_populate() has builtin: 1. large page support 2. device memory support 3. node locality support 4. several config based variants on diffe

Re: [PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-10-03 Thread Mark Rutland
Hi Pavel, On Wed, Sep 20, 2017 at 04:17:11PM -0400, Pavel Tatashin wrote: > During early boot, kasan uses vmemmap_populate() to establish its shadow > memory. But, that interface is intended for struct pages use. > > Because of the current project, vmemmap won't be zeroed during allocation, > but

[PATCH v9 09/12] mm/kasan: kasan specific map populate function

2017-09-20 Thread Pavel Tatashin
During early boot, kasan uses vmemmap_populate() to establish its shadow memory. But, that interface is intended for struct pages use. Because of the current project, vmemmap won't be zeroed during allocation, but kasan expects that memory to be zeroed. We are adding a new kasan_map_populate() fun