Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3417591iog; Mon, 20 Jun 2022 20:12:43 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vqzUbIueGNXDkUKBOYKJP+NQjd3Kg0TGiQpSU8QPyxtq/TMGc8K0bXURS9zItI5XgNyYYD X-Received: by 2002:a05:6a00:23d2:b0:525:25b9:233a with SMTP id g18-20020a056a0023d200b0052525b9233amr7485358pfc.20.1655781163745; Mon, 20 Jun 2022 20:12:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655781163; cv=none; d=google.com; s=arc-20160816; b=q1MO6iWvMTRTog7CMTvaFUcGEohoKnIdqX3ypGMJ5rUJCMsszHPDSfgMrAZv+61c5T 30RzyniHF9Qy8Ekb/fAqwNDezivwks1OGS+DnXbgD2UUVMLoPybXv5qq1/hzp3eSmR1c PhQKex2wQ+W0pslLIYbRVbugDX727eZMJiWbzKF+JMOKmL0HYkFtCioKDfjK4i/VibQZ bwSLHQHC6cQ7MG1XZpsMbZkRBJc+d5KDfJSmdjtbTmaPGq+Y9p87rhcZ/0IV7mT9hGW1 pqp6Me/+dyq9wb1mgzz2wHUJPMeolETqr9tSSNOERzcnM3HZTyNvnyP6FvyUyQuv5Aem cblg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=SOTUTSIgOH9Mv6qeDAyKgDPzOWsyyIl8RiHKGb/uYLY=; b=x1ZOgiAQtEVDfWdlFyowJONxSD+FApacgH66SD1vxgt3r/aNQa+9yTaBQ/4XvLKAV8 QIRGdUZ4vH7F+sqsrpWHZPDeJ9J8Wcn5UeAXgl76kFbRZAYWCXnnhKMzkkDxmPJg6P5v OW9jaMcbUR+rKTXk1cM3e5j/g1D0LVnYbz5PUozdF8XGv5q4o8PC5H8E5OqsVJCeJO3O Z2YIPv2QXHezn83o9mWhiiUzBPer1vLhkOtTZZolMa6oWWQoJLz9R3oIhpzwjeLNKXo+ faLOCyBHfhXLtxM6bS6jWB0ulOfKoT5/3qqcM82ISOgKRLTeerbwQQNEWe9j1D/0WU2Q BzjA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u29-20020a63141d000000b003ab2440ce56si15591171pgl.207.2022.06.20.20.12.30; Mon, 20 Jun 2022 20:12:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344834AbiFUDLg (ORCPT + 99 others); Mon, 20 Jun 2022 23:11:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40766 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344839AbiFUDL2 (ORCPT ); Mon, 20 Jun 2022 23:11:28 -0400 Received: from out199-9.us.a.mail.aliyun.com (out199-9.us.a.mail.aliyun.com [47.90.199.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7488F1F2FC for ; Mon, 20 Jun 2022 20:11:25 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0VH.Hjy._1655781080; Received: from localhost(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0VH.Hjy._1655781080) by smtp.aliyun-inc.com; Tue, 21 Jun 2022 11:11:20 +0800 From: Xianting Tian To: akpm@linux-foundation.org, david@redhat.com, ziy@nvidia.com Cc: guoren@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Xianting Tian Subject: [PATCH] mm: fixup validation of buddy pfn Date: Tue, 21 Jun 2022 11:11:18 +0800 Message-Id: <20220621031118.3650529-1-xianting.tian@linux.alibaba.com> X-Mailer: git-send-email 2.17.1 X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For RISC-V arch the first 2MB RAM could be reserved for opensbi, and the arch code may don't create pages for the first 2MB RAM, so it would have pfn_base=512 and mem_map began with 512th PFN when CONFIG_FLATMEM=y. But __find_buddy_pfn algorithm thinks the start PFN 0, it could get 0 PFN or less than the pfn_base value, so page_is_buddy() can't verify the page whose PFN is 0 ~ 511, actually we don't have valid pages for PFN 0 ~ 511. Actually, buddy system should not assume Arch cretaed pages for reserved memory, Arch may don't know the implied limitation. With this patch, we can gurantee a valid buddy no matter what we have pages for reserved memory or not. Fixes: 8170ac4700d26f65 ("mm: wrap __find_buddy_pfn() with a necessary buddy page validation") Signed-off-by: Xianting Tian --- mm/internal.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/internal.h b/mm/internal.h index c0f8fbe0445b..0ec446caeb2e 100644 --- a/mm/internal.h +++ b/mm/internal.h @@ -322,7 +322,8 @@ __find_buddy_pfn(unsigned long page_pfn, unsigned int order) * The found buddy can be a non PageBuddy, out of @page's zone, or its order is * not the same as @page. The validation is necessary before use it. * - * Return: the found buddy page or NULL if not found. + * Return: the found buddy page or NULL if not found or NULL if buddy pfn is + * not valid. */ static inline struct page *find_buddy_page_pfn(struct page *page, unsigned long pfn, unsigned int order, unsigned long *buddy_pfn) @@ -330,6 +331,9 @@ static inline struct page *find_buddy_page_pfn(struct page *page, unsigned long __buddy_pfn = __find_buddy_pfn(pfn, order); struct page *buddy; + if (!pfn_valid(__buddy_pfn)) + return NULL; + buddy = page + (__buddy_pfn - pfn); if (buddy_pfn) *buddy_pfn = __buddy_pfn; -- 2.17.1