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 A88BFC433DB for ; Tue, 16 Feb 2021 13:11:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 13DDD64D73 for ; Tue, 16 Feb 2021 13:11:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 13DDD64D73 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 8874F8D0178; Tue, 16 Feb 2021 08:11:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8102F8D0176; Tue, 16 Feb 2021 08:11:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FED38D0178; Tue, 16 Feb 2021 08:11:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0127.hostedemail.com [216.40.44.127]) by kanga.kvack.org (Postfix) with ESMTP id 5845D8D0176 for ; Tue, 16 Feb 2021 08:11:25 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2348B4DAB for ; Tue, 16 Feb 2021 13:11:25 +0000 (UTC) X-FDA: 77824167330.15.A9C1AEE Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf14.hostedemail.com (Postfix) with ESMTP id 201D6C0001FE for ; Tue, 16 Feb 2021 13:11:21 +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=1613481083; 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=Tu/09opR+rOaWunzc6yzJsQqaBcSy0Wetier3xAJdn4=; b=pwG37zROGA+8faCWLvy+Mf8FosYPMk8/PJ8dt1dtBwllWesrisk2vfB4D5gXvqF0weUMJj zIvbNC31ZflpX/m7QJRpotSmwfUnQQy11rAmmFdlGS733eAW1d4ax98IvmiEwD84RsGhGV v03nCahzJJXdkQMef0yVo4JjkmuO3r4= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 1AA64AF2C; Tue, 16 Feb 2021 13:11:23 +0000 (UTC) Date: Tue, 16 Feb 2021 14:11:21 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Mike Rapoport , 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 Subject: Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout Message-ID: References: <20210208110820.6269-1-rppt@kernel.org> <20210214180016.GO242749@kernel.org> <20210215212440.GA1307762@kernel.org> <20210216110154.GB1307762@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: trynf5ibt7us4gewbfy88moqnm3jin9p X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 201D6C0001FE Received-SPF: none (suse.com>: 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: pass/pass X-HE-Tag: 1613481081-441786 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 16-02-21 13:34:56, Vlastimil Babka wrote: > On 2/16/21 12:01 PM, Mike Rapoport wrote: > >> > >> 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 up > >> 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 do > >> and use as a hot fix which should be easier to backport. > > > > I can't say I'm familiar enough with migration and compaction code to say > > 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 write > outside of the pageblock bitmap for the zone, and corrupt something. Isn't it enough that at least some pfn from the pageblock belongs to the zone in order to have the bitmap allocated for the whole page block (even if it partially belongs to a different zone)? > Actually > 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 instead 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->zone. Thanks for looking deeper into that. This sounds like a much more targeted fix to me. > 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 pages 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. There might be some other cases but I think it would be better to have a single fix for this particular issue and have it fixed properly and only then build something more robust on top. -- Michal Hocko SUSE Labs