From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 499C7C2D0E4 for ; Fri, 20 Nov 2020 18:05:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B13F12245A for ; Fri, 20 Nov 2020 18:05:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="YBXhbNOM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B13F12245A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1BCD16B0072; Fri, 20 Nov 2020 13:05:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 193B06B0073; Fri, 20 Nov 2020 13:05:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0AA706B0074; Fri, 20 Nov 2020 13:05:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id D17D26B0072 for ; Fri, 20 Nov 2020 13:05:09 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 66D6F181AEF21 for ; Fri, 20 Nov 2020 18:05:09 +0000 (UTC) X-FDA: 77505573138.03.pear58_0408eff2734d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 3634328A4EC for ; Fri, 20 Nov 2020 18:05:09 +0000 (UTC) X-HE-Tag: pear58_0408eff2734d X-Filterd-Recvd-Size: 5725 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Nov 2020 18:05:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605895507; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=Cu8qL4szNEU63B2IWzbd6iRbLN7eMN3hJgKQ47FTKLo=; b=YBXhbNOMF7R8XZUnKAIZolS3WnxcS2Qbut6IatBu6wm2FBLApWVqnFStjQSM0BrqOpUp9/ 9IemcP9WATFSFLsXOPuibQvkXtgVysg2SM4RgUTuH/Bgnn9yLyvCd9mY+cmd0qTjwwHdKF jDGTQrwNHe902EkEYO1/vDFjhS9N6ck= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-403-GBRKpMGgPgSbCSLOwRc5XQ-1; Fri, 20 Nov 2020 13:05:02 -0500 X-MC-Unique: GBRKpMGgPgSbCSLOwRc5XQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9B84010151E7; Fri, 20 Nov 2020 18:05:00 +0000 (UTC) Received: from t480s.redhat.com (ovpn-114-78.ams2.redhat.com [10.36.114.78]) by smtp.corp.redhat.com (Postfix) with ESMTP id B43CE5D6AD; Fri, 20 Nov 2020 18:04:53 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, David Hildenbrand , Andrew Morton , Alexander Potapenko , Michal Hocko , Mike Kravetz , Vlastimil Babka , Mike Rapoport , Oscar Salvador , Kees Cook , Michael Ellerman Subject: [PATCH v2] mm/page_alloc: clear all pages in post_alloc_hook() with init_on_alloc=1 Date: Fri, 20 Nov 2020 19:04:52 +0100 Message-Id: <20201120180452.19071-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: commit 6471384af2a6 ("mm: security: introduce init_on_alloc=3D1 and init_on_free=3D1 boot options") resulted with init_on_alloc=3D1 in all pa= ges 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=3D1 and init_on_free=3D0. Let's also properly clear pages on that allocation path. To achieve that, let's move clearing into post_alloc_hook(). This will no= t only affect alloc_contig_pages() allocations but also any pages used as migration target in compaction code via compaction_alloc(). While this sounds sub-optimal, it's the very same handling as when allocating migration targets via alloc_migration_target() - pages will get properly cleared with init_on_free=3D1. In case we ever want to optim= ize migration in that regard, we should tackle all such migration users - if = we believe migration code can be fully trusted. 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=3D1 - 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. - Pages isolated for compaction will be cleared Cc: Andrew Morton Cc: Alexander Potapenko Cc: Michal Hocko Cc: Mike Kravetz Cc: Vlastimil Babka Cc: Mike Rapoport Cc: Oscar Salvador Cc: Kees Cook Cc: Michael Ellerman Signed-off-by: David Hildenbrand --- This is the follow-up of: "[PATCH v1] mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=3D1 or __GFP_ZERO" v1 -> v2: - Let's clear anything that leaves the buddy, also affecting compaction. - Don't implement __GFP_ZERO support for now --- mm/page_alloc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index eaa227a479e4..108b81c0dfa8 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2275,6 +2275,9 @@ inline void post_alloc_hook(struct page *page, unsi= gned int order, kasan_alloc_pages(page, order); kernel_poison_pages(page, 1 << order, 1); set_page_owner(page, order, gfp_flags); + + if (!free_pages_prezeroed() && want_init_on_alloc(gfp_flags)) + kernel_init_free_pages(page, 1 << order); } =20 static void prep_new_page(struct page *page, unsigned int order, gfp_t g= fp_flags, @@ -2282,9 +2285,6 @@ static void prep_new_page(struct page *page, unsign= ed int order, gfp_t gfp_flags { post_alloc_hook(page, order, gfp_flags); =20 - if (!free_pages_prezeroed() && want_init_on_alloc(gfp_flags)) - kernel_init_free_pages(page, 1 << order); - if (order && (gfp_flags & __GFP_COMP)) prep_compound_page(page, order); =20 --=20 2.26.2