From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Potapenko <glider@google.com>,
Michal Hocko <mhocko@suse.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Oscar Salvador <osalvador@suse.de>,
Kees Cook <keescook@chromium.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH v1] mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=1 or __GFP_ZERO
Date: Wed, 11 Nov 2020 11:59:09 +0200 [thread overview]
Message-ID: <20201111095909.GC4755@linux.ibm.com> (raw)
In-Reply-To: <20201110193240.25401-1-david@redhat.com>
On Tue, Nov 10, 2020 at 08:32:40PM +0100, David Hildenbrand wrote:
> 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@canonical.com
>
> 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.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Alexander Potapenko <glider@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Mike Rapoport <rppt@linux.ibm.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> mm/page_alloc.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index eed4f4075b3c..0361b119b74e 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -8453,6 +8453,19 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
> return 0;
> }
>
> +static void __alloc_contig_clear_range(unsigned long start_pfn,
> + unsigned long end_pfn)
Maybe clear_contig_range() ?
> +{
> + unsigned long pfn;
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += MAX_ORDER_NR_PAGES) {
> + cond_resched();
> + kernel_init_free_pages(pfn_to_page(pfn),
> + min_t(unsigned long, end_pfn - pfn,
> + MAX_ORDER_NR_PAGES));
> + }
> +}
> +
> /**
> * alloc_contig_range() -- tries to allocate given range of pages
> * @start: start PFN to allocate
> @@ -8461,7 +8474,8 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
> * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks
> * in range must have the same migratetype and it must
> * be either of the two.
> - * @gfp_mask: GFP mask to use during compaction
> + * @gfp_mask: GFP mask to use during compaction. __GFP_ZERO clears allocated
> + * pages.
"__GFP_ZERO is not passed to compaction but rather clears allocated pages"
> *
> * The PFN range does not have to be pageblock or MAX_ORDER_NR_PAGES
> * aligned. The PFN range must belong to a single zone.
> @@ -8488,7 +8502,7 @@ int alloc_contig_range(unsigned long start, unsigned long end,
> .mode = MIGRATE_SYNC,
> .ignore_skip_hint = true,
> .no_set_skip_hint = true,
> - .gfp_mask = current_gfp_context(gfp_mask),
> + .gfp_mask = current_gfp_context(gfp_mask & ~__GFP_ZERO),
> .alloc_contig = true,
> };
> INIT_LIST_HEAD(&cc.migratepages);
> @@ -8600,6 +8614,9 @@ int alloc_contig_range(unsigned long start, unsigned long end,
> if (end != outer_end)
> free_contig_range(end, outer_end - end);
>
> + if (!want_init_on_free() && want_init_on_alloc(gfp_mask))
> + __alloc_contig_clear_range(start, end);
> +
> done:
> undo_isolate_page_range(pfn_max_align_down(start),
> pfn_max_align_up(end), migratetype);
> @@ -8653,7 +8670,8 @@ static bool zone_spans_last_pfn(const struct zone *zone,
> /**
> * alloc_contig_pages() -- tries to find and allocate contiguous range of pages
> * @nr_pages: Number of contiguous pages to allocate
> - * @gfp_mask: GFP mask to limit search and used during compaction
> + * @gfp_mask: GFP mask to limit search and used during compaction. __GFP_ZERO
> + * clears allocated pages.
> * @nid: Target node
> * @nodemask: Mask for other possible nodes
> *
> --
> 2.26.2
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2020-11-11 9:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 19:32 [PATCH v1] mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=1 or __GFP_ZERO David Hildenbrand
2020-11-11 8:47 ` Michal Hocko
2020-11-11 9:06 ` David Hildenbrand
2020-11-11 9:58 ` Vlastimil Babka
2020-11-11 10:05 ` David Hildenbrand
2020-11-11 10:22 ` Michal Hocko
2020-11-11 10:32 ` David Hildenbrand
2020-11-11 9:25 ` David Hildenbrand
2020-11-11 9:59 ` Mike Rapoport [this message]
2020-11-11 10:06 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201111095909.GC4755@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=glider@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=osalvador@suse.de \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox