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 3B2F8C433E6 for ; Tue, 16 Feb 2021 13:00:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 10BDD64D73 for ; Tue, 16 Feb 2021 13:00:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230018AbhBPNAl (ORCPT ); Tue, 16 Feb 2021 08:00:41 -0500 Received: from mx2.suse.de ([195.135.220.15]:41930 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229895AbhBPNAi (ORCPT ); Tue, 16 Feb 2021 08:00:38 -0500 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 3F416AF2C; Tue, 16 Feb 2021 12:59:54 +0000 (UTC) Subject: Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout From: Vlastimil Babka 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> Message-ID: Date: Tue, 16 Feb 2021 13:59:52 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/16/21 1:34 PM, 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. Actually Clarification. This is true only for !CONFIG_SPARSEMEM, which is unlikely in practice to produce the configurations that trigger this issue. So we can remove the VM_BUG_ON_PAGE() > 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. > 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. > > > >