# Re: \[PATCH v4\] mm: introduce reference pages

- From: John Hubbard \<jhubbard@nvidia.com\>
- Date: 2021-07-19 22:31:37 
- List: linux-arm-kernel
- Page: https://ratatoskr.run/linux-arm-kernel/2021/07/6509950
- Thread: https://ratatoskr.run/linux-arm-kernel/2021/06/6508943/t.md

```text
On 7/19/21 3:26 PM, Peter Collingbourne wrote:
...
>>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
>>> index 55b2ec1f965a..ae3c763eb9e9 100644
>>> --- a/include/linux/gfp.h
>>> +++ b/include/linux/gfp.h
>>> @@ -55,8 +55,9 @@ struct vm_area_struct;
>>>    #define ___GFP_ACCOUNT              0x400000u
>>>    #define ___GFP_ZEROTAGS             0x800000u
>>>    #define ___GFP_SKIP_KASAN_POISON    0x1000000u
>>> +#define ___GFP_NOZERO                0x2000000u
>>
>> Oh god, please no. We've discussed this a couple of times already:
>> whatever leaves the page allcoator shall be zeroed. No exceptions, not
>> even for other allocators (like hugetlb).
>>
>> Introducing something like that to the whole system, including random
>> drivers, destroys the whole purpose of the security feature. Please
>> don't burry something so controversial in your patch.
>
> Got it -- I was unaware that this was controversial.
>
> Avoiding the double initialization does help a bit in benchmarks, at
> least for the fully faulted case. The alternative approach that I was
> thinking of was to somehow plumb the required pattern into the page
> allocator (which would maintain the invariant that the pages are
> initialized, but not necessarily with zeroes), but this would require
> touching several layers of the allocator.  I suppose that this doesn't

That sounds right.

> need to be done immediately though -- we can deal with the double
> initialization for now and avoid it somehow in a followup.
>

Actually, I'd encourage going straight to the final result, in this
case. It's good to see what we are going to end up with, and figure
out if it's worth the trade-offs.


thanks,
-- 
John Hubbard
NVIDIA

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
```