On 10.11.20 21:08, akpm@xxxxxxxxxxxxxxxxxxxx wrote: > > The patch titled > Subject: mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=1 or __GFP_ZERO > has been added to the -mm tree. Its filename is > mm-page_alloc-clear-pages-in-alloc_contig_pages-with-init_on_alloc=1-or-__gfp_zero.patch > > This patch should soon appear at > https://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-clear-pages-in-alloc_contig_pages-with-init_on_alloc%3D1-or-__gfp_zero.patch > and later at > https://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-clear-pages-in-alloc_contig_pages-with-init_on_alloc%3D1-or-__gfp_zero.patch > > Before you just go and hit "reply", please: > a) Consider who else should be cc'ed > b) Prefer to cc a suitable mailing list as well > c) Ideally: find the original patch on the mailing list and do a > reply-to-all to that, adding suitable additional cc's > > *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** > > The -mm tree is included into linux-next and is updated > there every 3-4 working days > > ------------------------------------------------------ > From: David Hildenbrand <david@xxxxxxxxxx> > Subject: mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=1 or __GFP_ZERO > > commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and > init_on_free=1 boot options") resulted with init_on_alloc=1 in all pages > leaving the buddy via alloc_pages() and friends to be > initialized/cleared/zeroed on allocation. > > However, the same logic is currently not applied to alloc_contig_pages(): > allocated pages leaving the buddy aren't cleared with init_on_alloc=1 and > init_on_free=0. Let's also properly clear pages on that allocation path > and add support for __GFP_ZERO. > > With this change, we will see double clearing of pages in some cases. One > example are gigantic pages (either allocated via CMA, or allocated > dynamically via alloc_contig_pages()) - which is the right thing to do > (and to be optimized outside of the buddy in the callers) as discussed in > https://lkml.kernel.org/r/20201019182853.7467-1-gpiccoli@xxxxxxxxxxxxx > > This change implies that with init_on_alloc=1 > - All CMA allocations will be cleared > - Gigantic pages allocated via alloc_contig_pages() will be cleared > - virtio-mem memory to be unplugged will be cleared. While this is > suboptimal, it's similar to memory balloon drivers handling, where > all pages to be inflated will get cleared as well. > > Link: https://lkml.kernel.org/r/20201110193240.25401-1-david@xxxxxxxxxx > Signed-off-by: David Hildenbrand <david@xxxxxxxxxx> > Cc: Alexander Potapenko <glider@xxxxxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxxx> > Cc: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > Cc: Vlastimil Babka <vbabka@xxxxxxx> > Cc: Mike Rapoport <rppt@xxxxxxxxxxxxx> > Cc: Oscar Salvador <osalvador@xxxxxxx> > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > Cc: Michael Ellerman <mpe@xxxxxxxxxxxxxx> > Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > --- @Andrew, can you unqueue this one now that we have https://lkml.kernel.org/r/20201120180452.19071-1-david@xxxxxxxxxx ? Thanks! -- Thanks, David / dhildenb
