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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 39EBFC433E0 for ; Tue, 16 Feb 2021 12:35:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A01B864DDA for ; Tue, 16 Feb 2021 12:35:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A01B864DDA Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 983B08D0175; Tue, 16 Feb 2021 07:35:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 932FD8D0140; Tue, 16 Feb 2021 07:35:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 847F38D0175; Tue, 16 Feb 2021 07:35:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 6EA078D0140 for ; Tue, 16 Feb 2021 07:35:01 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2D31D87C6 for ; Tue, 16 Feb 2021 12:35:01 +0000 (UTC) X-FDA: 77824075602.24.1A984BF Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf14.hostedemail.com (Postfix) with ESMTP id 4E284C0001EE for ; Tue, 16 Feb 2021 12:34:57 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2A3EDB0BD; Tue, 16 Feb 2021 12:34:59 +0000 (UTC) To: Mike Rapoport , Michal Hocko Cc: Mel Gorman , David Hildenbrand , Andrew Morton , Andrea Arcangeli , Baoquan He , Borislav Petkov , Chris Wilson , "H. Peter Anvin" , Ingo Molnar , Linus Torvalds , =?UTF-8?Q?=c5=81ukasz_Majczak?= , Mike Rapoport , Qian Cai , "Sarvela, Tomi P" , Thomas Gleixner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, x86@kernel.org References: <20210208110820.6269-1-rppt@kernel.org> <20210214180016.GO242749@kernel.org> <20210215212440.GA1307762@kernel.org> <20210216110154.GB1307762@kernel.org> From: Vlastimil Babka Subject: Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout Message-ID: Date: Tue, 16 Feb 2021 13:34:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <20210216110154.GB1307762@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Stat-Signature: sar5opt9zy63n5w9qaim73w3xbxftnar X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4E284C0001EE Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf14; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1613478897-746167 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: On 2/16/21 12:01 PM, Mike Rapoport wrote: >>=20 >> I do understand that. And I am not objecting to the patch. I have to >> confess I haven't digested it yet. Any changes to early memory >> intialization have turned out to be subtle and corner cases only pop u= p >> later. This is almost impossible to review just by reading the code. >> That's why I am asking whether we want to address the specific VM_BUG_= ON >> first with something much less tricky and actually reviewable. And >> that's why I am asking whether dropping the bug_on itself is safe to d= o >> and use as a hot fix which should be easier to backport. >=20 > I can't say I'm familiar enough with migration and compaction code to s= ay > if it's ok to remove that bug_on. It does point to inconsistency in the > memmap, but probably it's not important. On closer look, removing the VM_BUG_ON_PAGE() in set_pfnblock_flags_mask(= ) is not safe. If we violate the zone_spans_pfn condition, it means we will wr= ite outside of the pageblock bitmap for the zone, and corrupt something. Actu= ally similar thing can happen in __get_pfnblock_flags_mask() where there's no VM_BUG_ON, but there we can't corrupt memory. But we could theoretically = fault to do accessing some unmapped range? So the checks would have to become unconditional !DEBUG_VM and return ins= tead of causing a BUG. Or we could go back one level and add some checks to fast_isolate_around() to detect a page from zone that doesn't match cc->z= one. The question is if there is another code that will break if a page_zone() suddenly changes e.g. in the middle of the pageblock - __pageblock_pfn_to= _page() assumes that if first and last page is from the same zone, so are all pag= es in between, and the rest relies on that. But maybe if Andrea's fast_isolate_around() issue is fixed, that's enough for stable backport.