Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp190783pxb; Wed, 11 Nov 2020 00:50:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJyZaDHqpR4NDusUYuZM5vo0WPH72z34eib+NxDJ4E0m/g0zNJBZJYs5x1C9vLVrki0DnaPv X-Received: by 2002:aa7:df89:: with SMTP id b9mr25665781edy.335.1605084622483; Wed, 11 Nov 2020 00:50:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605084622; cv=none; d=google.com; s=arc-20160816; b=luLXJgXT0MYU9s4sWIsLEeWX99lCeFVzO3vOcS81wnIV4hdXD6J2+/7ZQwuRETSLWy Io5dcdMIW9svx7WgdNyXBEjkyJFVrSM+9IMPE5y2OfmtWZGvEg+RQaV8QpZD+3wACsN0 HXTy8dVqAVCaAYhcD29mWzmtQjjoBnlQOvbaYj3hyqeHufP27dmXqVSe1JW8Y1rt/qhC i+8bhL+7inguA2y7+0h6crHLtAoyf254oTHlwW3bUE0tQS44FEdrYDLcxN9qIW0m2YbR 0K6NioZZ99XhN+0qf7ofaPGPcD5JqExhICcwt8eLi8BehNSoabJKop+NeaYWFq8T9APD jU4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TbUcoHl5z9AxdFqijGPjTFtzVgBuvmu8IH2Bj4tg8Xk=; b=TBbKAbal78ow+w7M3VmIDPjahTlK60RQdxYbXWlNWL5ffWOmopgxU6qXC6+CC2Cr1v 11xvx2NSfmJ6w3Wj0JoiO7/LRSWxOdgf/2UD28D9E64D25B4UtD3L1hCIUwwi77kqJjT ACkwqxLZ3inv1WAe/AC0p9MqwYf5LUBLpUx9mg2cBBV9/UM1KPknhJ89AITFkiZuaVrN 6YMTx5oZDrL3R3kHTpfcS3m4duzMrB2eSo13sj4zpRAxKCe3oxKard3SU4ioZTCVlocE D/wGDnTyJpKBAQyADwv9suwWrjGFUic5Lfo/5evH4ADnlF7FHlJMmT5KpusO4A4/aJTs 6PEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=WebGNYwm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v3si860188ejq.157.2020.11.11.00.49.59; Wed, 11 Nov 2020 00:50:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=WebGNYwm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726026AbgKKIrm (ORCPT + 99 others); Wed, 11 Nov 2020 03:47:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:58386 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725859AbgKKIrk (ORCPT ); Wed, 11 Nov 2020 03:47:40 -0500 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> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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