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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78499C433EF for ; Tue, 21 Jun 2022 03:11:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19AAB6B0072; Mon, 20 Jun 2022 23:11:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14A5D6B0073; Mon, 20 Jun 2022 23:11:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0390E8E0001; Mon, 20 Jun 2022 23:11:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E924C6B0072 for ; Mon, 20 Jun 2022 23:11:26 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BBAF4F84 for ; Tue, 21 Jun 2022 03:11:26 +0000 (UTC) X-FDA: 79600767372.08.D8C52B2 Received: from out199-12.us.a.mail.aliyun.com (out199-12.us.a.mail.aliyun.com [47.90.199.12]) by imf12.hostedemail.com (Postfix) with ESMTP id 4742640015 for ; Tue, 21 Jun 2022 03:11:24 +0000 (UTC) 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655781086; a=rsa-sha256; cv=none; b=Oo+pnzeqc6bErmOkmH6ZWaq3poXMxLVAsl1AZD5wQLRoHNBvGcwKARw39meuPuU46ejn4I beSPFIxI12aU2BgD1bzU9NuRjPOj1GiZSXajpYo0OulX9+Y4/wbevEAFxvsz5cBJIA4Fj1 Zh7iNn+bGVnFjs3RZlyhIj1KqSdB6e0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of xianting.tian@linux.alibaba.com designates 47.90.199.12 as permitted sender) smtp.mailfrom=xianting.tian@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655781086; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=SOTUTSIgOH9Mv6qeDAyKgDPzOWsyyIl8RiHKGb/uYLY=; b=dVc9nyRdH+Xi4wFTeA8njt5SlwrD/MLTHjxp0xjEORubxSIYfHQ6TQj2tgz4IfNE0soRwO SJxBBJ29xWz0wuHLN5lnSX0+eSoZD5I6A9Xq0tncAOG4T0RJI13ELQ9flmIGeHtl3AokXZ UDHXpsGxFk3AkPj6nfQZw2c8oJFjJrA= Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of xianting.tian@linux.alibaba.com designates 47.90.199.12 as permitted sender) smtp.mailfrom=xianting.tian@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Rspam-User: X-Stat-Signature: 3qy4k1gfkw4d5tnzjjwexfo3w48xonfb X-Rspamd-Queue-Id: 4742640015 X-Rspamd-Server: rspam08 X-HE-Tag: 1655781084-230290 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: 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