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=-5.8 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 84B5FC433ED for ; Wed, 14 Apr 2021 08:28:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B646613C4 for ; Wed, 14 Apr 2021 08:28:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B646613C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine 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 913A06B0078; Wed, 14 Apr 2021 04:28:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C3006B007B; Wed, 14 Apr 2021 04:28:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78B0F6B007D; Wed, 14 Apr 2021 04:28:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 5F81F6B0078 for ; Wed, 14 Apr 2021 04:28:36 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1531C180199CB for ; Wed, 14 Apr 2021 08:28:36 +0000 (UTC) X-FDA: 78030296232.38.6096B8B Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP id 4A6D640002D7 for ; Wed, 14 Apr 2021 08:28:31 +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=1618388914; h=from:from:reply-to: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=77PvjZ043bsPpk7w1CZMRpSRItMCMDE42Gsr4nMRZ10=; b=OIfRDOnWexsq0i9cJ27GBfwAJRtJM3CVyiFWjghiXXOjWMVtpqabpZp9AfZOFNXEWqYkt2 r0suOuQjj739ngmFG3qrLvq/GrHoA6l+Ot9PeIRnIhz4ZMG389ew9/gV8Wpi/Nn1q8TwSz LF2xqEkkzzrhKtpfzzkHkAw/tvo5Lwk= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 48574ACC4; Wed, 14 Apr 2021 08:28:34 +0000 (UTC) Date: Wed, 14 Apr 2021 10:28:33 +0200 From: Michal Hocko To: Oscar Salvador Cc: Mike Kravetz , Andrew Morton , Vlastimil Babka , David Hildenbrand , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 3/7] mm,hugetlb: Clear HPageFreed outside of the lock Message-ID: References: <20210413104747.12177-1-osalvador@suse.de> <20210413104747.12177-4-osalvador@suse.de> <20210414074132.GB20401@linux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210414074132.GB20401@linux> X-Rspamd-Queue-Id: 4A6D640002D7 X-Stat-Signature: jtd6tobeo8ztedxq9nkqkpp6h3p6ujp3 X-Rspamd-Server: rspam02 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618388911-842217 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 Wed 14-04-21 09:41:32, Oscar Salvador wrote: > On Wed, Apr 14, 2021 at 08:04:21AM +0200, Michal Hocko wrote: > > On Tue 13-04-21 14:19:03, Mike Kravetz wrote: > > > On 4/13/21 6:23 AM, Michal Hocko wrote: > > > The only place where page->private may not be initialized is when we do > > > allocations at boot time from memblock. In this case, we will add the > > > pages to the free list via put_page/free_huge_page so the appropriate > > > flags will be cleared before anyone notices. > > > > Pages allocated by the bootmem should be pre initialized from the boot, > > no? > > I guess Mike means: > > hugetlb_hstate_alloc_pages > alloc_bootmem_huge_page > __alloc_bootmem_huge_page > memblock_alloc_try_nid_raw > > and AFAICS, memblock_alloc_try_nid_raw() does not zero the memory. You are right it doesn't do it there. But all struct pages, even those that are allocated by the bootmem allocator should initialize its struct pages. They would be poisoned otherwise, right? I would have to look at the exact code path but IIRC this should be around the time bootmem allocator state transitions to the page allocator. -- Michal Hocko SUSE Labs