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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 2BC0AC4742C for ; Wed, 11 Nov 2020 08:47:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7028F206E3 for ; Wed, 11 Nov 2020 08:47:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=suse.com header.i=@suse.com header.b="WebGNYwm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7028F206E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 786F16B0068; Wed, 11 Nov 2020 03:47:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 739F36B006C; Wed, 11 Nov 2020 03:47:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D9B56B006E; Wed, 11 Nov 2020 03:47:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 303316B0068 for ; Wed, 11 Nov 2020 03:47:42 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D10DE181AEF00 for ; Wed, 11 Nov 2020 08:47:41 +0000 (UTC) X-FDA: 77471509122.21.shop18_1603f74272fc Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin21.hostedemail.com (Postfix) with ESMTP id B0B51180442C0 for ; Wed, 11 Nov 2020 08:47:41 +0000 (UTC) X-HE-Tag: shop18_1603f74272fc X-Filterd-Recvd-Size: 3015 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Nov 2020 08:47:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1605084459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TbUcoHl5z9AxdFqijGPjTFtzVgBuvmu8IH2Bj4tg8Xk=; b=WebGNYwmHHaNeLjCPTRxNq9r9xLrGsTbQp490G6s8FsRx6Hb/vyLAQDuXFA1B1IFSt/tNJ 8Niq9M1L0IzP0tdzACdYCFWzgvGKoPnhsRzCEQJIdvEZBxrgjzJ1YLB0O7DaQHz/0dsFpR uoY9W6aT+RzNpVgQAUrNKO63m2SdS10= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C7F8FABD6; Wed, 11 Nov 2020 08:47:39 +0000 (UTC) Date: Wed, 11 Nov 2020 09:47:38 +0100 From: Michal Hocko To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Alexander Potapenko , Mike Kravetz , Vlastimil Babka , Mike Rapoport , Oscar Salvador , Kees Cook , Michael Ellerman Subject: Re: [PATCH v1] mm/page_alloc: clear pages in alloc_contig_pages() with init_on_alloc=1 or __GFP_ZERO Message-ID: <20201111084738.GT12240@dhcp22.suse.cz> References: <20201110193240.25401-1-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201110193240.25401-1-david@redhat.com> 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: On Tue 10-11-20 20:32:40, 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. AFAIR we do not have any user for __GFP_ZERO right? Not that this is harmful but it is better to call that explicitly because a missing implementation would be a real problem and as such a bug fix. I am also not sure handling init_on_free at the higher level is good. As we have discussed recently the primary point of this feature is to add clearing at very few well defined entry points rather than spill it over many places. In this case the entry point for the allocator is __isolate_free_page which removes pages from the page allocator. I haven't checked how much this is used elsewhere but I would expect init_on_alloc to be handled there. -- Michal Hocko SUSE Labs