On 7/19/21 3:26 PM, Peter Collingbourne wrote:
...

quoted

quoted

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