From patchwork Wed Oct 30 13:11:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vincent Whitchurch X-Patchwork-Id: 11219543 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 2203F912 for ; Wed, 30 Oct 2019 13:11:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB8A920874 for ; Wed, 30 Oct 2019 13:11:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB8A920874 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=axis.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1CE0D6B0003; Wed, 30 Oct 2019 09:11:31 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 17EF66B0006; Wed, 30 Oct 2019 09:11:31 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 094E36B0007; Wed, 30 Oct 2019 09:11:31 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0243.hostedemail.com [216.40.44.243]) by kanga.kvack.org (Postfix) with ESMTP id DECE46B0003 for ; Wed, 30 Oct 2019 09:11:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 879372C14 for ; Wed, 30 Oct 2019 13:11:30 +0000 (UTC) X-FDA: 76100487540.15.part65_d0a516e8c248 X-Spam-Summary: 1,0,0,,d41d8cd98f00b204,vincent.whitchurch@axis.com,:akpm@linux-foundation.org:osalvador@suse.de:mhocko@suse.com:pasha.tatashin@oracle.com::linux-kernel@vger.kernel.org:rabinv@axis.com,RULES_HIT:30012:30054,0,RBL:195.60.68.18:@axis.com:.lbl8.mailshell.net-62.18.203.100 64.95.201.95,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: part65_d0a516e8c248 X-Filterd-Recvd-Size: 2713 Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 13:11:29 +0000 (UTC) IronPort-SDR: 4yyDR3sJFKrKPKpLcaUxoo9d9+Pa0Ek0erNLQarTDt+8/VKUKoAxoJCgSezeapCwfUIGpDd1iN 4QjHBoj3+5egc0nG5FUaM5YNEYdj0KlEdYCA3Ms8u1oRauTzxovDOLJVdG3RGhg79S1qUEri7+ Uin78f580QoK6o98KzsmYYqyIeDnwu1P2zl82et/DWYeC2jAoAcg7k/1Cx2kM2GvQ4A5kVVtQY fGTSJ2CwXNfFRh3rwyxqaD1WUUzm6T7ZkwDMKWZFw/i9V2j/NBIIInkg2XuJWQ9GRUr1K/Axmp qPE= X-IronPort-AV: E=Sophos;i="5.68,247,1569276000"; d="scan'208";a="1923405" X-Axis-User: NO X-Axis-NonUser: YES X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com From: Vincent Whitchurch To: akpm@linux-foundation.org Cc: osalvador@suse.de, mhocko@suse.com, pasha.tatashin@oracle.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vincent Whitchurch Subject: [PATCH] mm/sparse: Consistently do not zero memmap Date: Wed, 30 Oct 2019 14:11:22 +0100 Message-Id: <20191030131122.8256-1-vincent.whitchurch@axis.com> X-Mailer: git-send-email 2.20.0 MIME-Version: 1.0 X-TM-AS-GCONF: 00 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: sparsemem without VMEMMAP has two allocation paths to allocate the memory needed for its memmap (done in sparse_mem_map_populate()). In one allocation path (sparse_buffer_alloc() succeeds), the memory is not zeroed (since it was previously allocated with memblock_alloc_try_nid_raw()). In the other allocation path (sparse_buffer_alloc() fails and sparse_mem_map_populate() falls back to memblock_alloc_try_nid()), the memory is zeroed. AFAICS this difference does not appear to be on purpose. If the code is supposed to work with non-initialized memory (__init_single_page() takes care of zeroing the struct pages which are actually used), we should consistently not zero the memory, to avoid masking bugs. (I noticed this because on my ARM64 platform, with 1 GiB of memory the first [and only] section is allocated from the zeroing path while with 2 GiB of memory the first 1 GiB section is allocated from the non-zeroing path.) Signed-off-by: Vincent Whitchurch Acked-by: Michal Hocko Acked-by: David Hildenbrand Reviewed-by: Oscar Salvador Reviewed-by: Pavel Tatashin --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/sparse.c b/mm/sparse.c index f6891c1992b1..01e467adc219 100644 --- a/mm/sparse.c +++ b/mm/sparse.c @@ -458,7 +458,7 @@ struct page __init *__populate_section_memmap(unsigned long pfn, if (map) return map; - map = memblock_alloc_try_nid(size, + map = memblock_alloc_try_nid_raw(size, PAGE_SIZE, addr, MEMBLOCK_ALLOC_ACCESSIBLE, nid); if (!map)