From patchwork Fri Jan 3 09:20:23 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Xu Lu X-Patchwork-Id: 13925417 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 48BD9E77188 for ; Fri, 3 Jan 2025 09:20:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=txi0nCx2Shb0d+InIq0npmj5cWfwPsJr46SQv3brQY8=; b=buiJSGiMMVRhXf tPggYnJVdeSh5ojQfUEM9UncBOf8OKDOB7q02iqX1WK6o0PsMirFMbmGjmNb4XDGJbANhXB6szJrz kvgh4t8XST17MHHcVY7F38JyFIxp+s+WZZjuGVSBSAKFxgyb4EA9rTLC8ShL7TGrRUR1VLhDfem+q di7fVTw2Uav2vZMz8SqzqZY7Buy9khXOZ+RFlFq0xeK15ry1ksqpbDlceyQEpoPynQboluCQxDF8J 4q/LZThnI2u4qE/QuGp79HHoVYL/lbh25ZQ65n6dLEYLu12ndKDbjMrT7agHkI1FMfXmyFj23zzm7 iIZM6no6wGqw+o8KgvEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tTdrC-0000000CaUB-2617; Fri, 03 Jan 2025 09:20:38 +0000 Received: from mail-pl1-x632.google.com ([2607:f8b0:4864:20::632]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tTdr8-0000000CaRe-41DK for linux-riscv@lists.infradead.org; Fri, 03 Jan 2025 09:20:36 +0000 Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-2161eb94cceso117753975ad.2 for ; Fri, 03 Jan 2025 01:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1735896031; x=1736500831; darn=lists.infradead.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=ET8b8sRPCO4IU1SFY+SvkpPtWQBm6OdnGtfJMT58fac=; b=FsLZIKL4jLE+qepR/ttPjNgz6izo65cbirsQ4PdwM+aIkn/jpQ+F8rhXAIGx8/F08T hEzYt+vAVGZfXZBrC+WkAUc91/PvMg/o5bINHHvTkk3LiYVlI1NXwz6AYCbXnHsVSoXX oMylN0crsEA4n15xyopSlNm3vCfl3FkABZWqf487z7lONDKcJpGBlWbkSmc4AAZovtTC G3CMTwt7xciEya9h3ilZSiU8oD+Tpx/R/+ftTizCFGwD5aoQwyDSE4VU4yv2vYIymh/Y e2qiNZjFBEOex5RS9fPXTiUxJqBq4V7bLXh8d1hGmZY9Qv/Mn1YwpjSBuBRlO5VTuiAa FBQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735896031; x=1736500831; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ET8b8sRPCO4IU1SFY+SvkpPtWQBm6OdnGtfJMT58fac=; b=wM0uvRBDuW/4w2NjEU84+9knykn2uZHpZtfgHaw3gvlcisrtP9ZkjIvsb7EVOIoASg ajtwRjtN2WffnrCEWXSFiiJM66Y0Cj7XU3xPtXBYSSfLVBgO1ZUmlt231WL/66/G2nGQ ZfxBdggQ4gVyUgDP0F0HDX413TqxGS0J+lKwa0FmuV2tfPm9BrX+nmgkExiHkdtOI9yv zCdB/43JH1ePZyBiSFAtZhriUZq0+mrCXuy2TiErSe+OLZ3suIn+5clYMNLUpDTJ7e75 gDqR+aeZeq7CZvlDIsj/KghX2BLnocajxJQ56QjBK61juHFHjlwt8QMJ2KII63JZpdGz u3EQ== X-Forwarded-Encrypted: i=1; AJvYcCXHFLJP23cgSrJH5MkQ65VMmwv81bgnI0wP+fwXIaU9+2SfCyeERQ6sBNn2JCDYcn1GVXtoCl/tyJSk6Q==@lists.infradead.org X-Gm-Message-State: AOJu0YwKkLMj80nGnn+rYgpxMX2iR24q11VIhAogLI3+GPZQ7uYXn+D5 Vy1xq/cj3BuvP2Mk3lJ637msiLBPdCr1R9zNE2E9wqUfK1etDT8hdRLd5dQkRRG1KVcSwcJGSDJ Ybcc= X-Gm-Gg: ASbGncsP9XZdN4Hr90mHbalvPkQheQxTTGDcarEugM3ATmSTP6mQ8i2eygeoHs2c33L zqe2pVbgXXC39aZX/OsfO3H4KhrhDB4R0AQYwW9YMqp1+XblRxcaRJFRNEGdHFRJzLr4ypA4Y0l VaSMvM5tTCs/DV0lp4LH480ZiPYUuyGLTgy9UVzEWZfqsG3ybMbmzu0cvAYjQPJRvgiIjB6T7YS /TdaEokZ1R4A/Xbl+oISaAGSCeNUO1Oulkqjus8YaeCe6gsQX8/ycWVudszzglftiEq/ieQmfWX 4bdWbyQvT2CQKPG7F0ygj23Xz3rGdlaLdoYNI20= X-Google-Smtp-Source: AGHT+IFfovCSRx3AcqtkWwLuhdout5NOGCAZSfyM3+u+DoqFfMNkSSa+F+IUKGlVCWqGfXK4bOVy9g== X-Received: by 2002:a17:902:d2c9:b0:216:4c88:d939 with SMTP id d9443c01a7336-219e6f133b6mr716758005ad.38.1735896030803; Fri, 03 Jan 2025 01:20:30 -0800 (PST) Received: from J9GPGXL7NT.bytedance.net ([61.213.176.55]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-219dc96e585sm241417515ad.70.2025.01.03.01.20.27 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 03 Jan 2025 01:20:30 -0800 (PST) From: Xu Lu To: paul.walmsley@sifive.com, palmer@dabbelt.com, alexghiti@rivosinc.com, bjorn@rivosinc.com Cc: lihangjing@bytedance.com, xieyongji@bytedance.com, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Xu Lu Subject: [PATCH RESEND v4] riscv: mm: Fix the out of bound issue of vmemmap address Date: Fri, 3 Jan 2025 17:20:23 +0800 Message-Id: <20250103092023.37083-1-luxu.kernel@bytedance.com> X-Mailer: git-send-email 2.39.5 (Apple Git-154) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250103_012034_994471_161095EA X-CRM114-Status: GOOD ( 17.70 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)). However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page. For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END. This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base. Fixes: a11dd49dcb93 ("riscv: Sparse-Memory/vmemmap out-of-bounds fix") Tested-by: Björn Töpel Reviewed-by: Björn Töpel Reviewed-by: Alexandre Ghiti Signed-off-by: Xu Lu --- arch/riscv/include/asm/page.h | 1 + arch/riscv/include/asm/pgtable.h | 2 +- arch/riscv/mm/init.c | 17 ++++++++++++++++- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h index 71aabc5c6713..125f5ecd9565 100644 --- a/arch/riscv/include/asm/page.h +++ b/arch/riscv/include/asm/page.h @@ -122,6 +122,7 @@ struct kernel_mapping { extern struct kernel_mapping kernel_map; extern phys_addr_t phys_ram_base; +extern unsigned long vmemmap_start_pfn; #define is_kernel_mapping(x) \ ((x) >= kernel_map.virt_addr && (x) < (kernel_map.virt_addr + kernel_map.size)) diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index d4e99eef90ac..050fdc49b5ad 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -87,7 +87,7 @@ * Define vmemmap for pfn_to_page & page_to_pfn calls. Needed if kernel * is configured with CONFIG_SPARSEMEM_VMEMMAP enabled. */ -#define vmemmap ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)) +#define vmemmap ((struct page *)VMEMMAP_START - vmemmap_start_pfn) #define PCI_IO_SIZE SZ_16M #define PCI_IO_END VMEMMAP_START diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index fc53ce748c80..8d167e09f1fe 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include "../kernel/head.h" @@ -62,6 +63,13 @@ EXPORT_SYMBOL(pgtable_l5_enabled); phys_addr_t phys_ram_base __ro_after_init; EXPORT_SYMBOL(phys_ram_base); +#ifdef CONFIG_SPARSEMEM_VMEMMAP +#define VMEMMAP_ADDR_ALIGN (1ULL << SECTION_SIZE_BITS) + +unsigned long vmemmap_start_pfn __ro_after_init; +EXPORT_SYMBOL(vmemmap_start_pfn); +#endif + unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss; EXPORT_SYMBOL(empty_zero_page); @@ -240,8 +248,12 @@ static void __init setup_bootmem(void) * Make sure we align the start of the memory on a PMD boundary so that * at worst, we map the linear mapping with PMD mappings. */ - if (!IS_ENABLED(CONFIG_XIP_KERNEL)) + if (!IS_ENABLED(CONFIG_XIP_KERNEL)) { phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; +#ifdef CONFIG_SPARSEMEM_VMEMMAP + vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT; +#endif + } /* * In 64-bit, any use of __va/__pa before this point is wrong as we @@ -1101,6 +1113,9 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa) kernel_map.xiprom_sz = (uintptr_t)(&_exiprom) - (uintptr_t)(&_xiprom); phys_ram_base = CONFIG_PHYS_RAM_BASE; +#ifdef CONFIG_SPARSEMEM_VMEMMAP + vmemmap_start_pfn = round_down(phys_ram_base, VMEMMAP_ADDR_ALIGN) >> PAGE_SHIFT; +#endif kernel_map.phys_addr = (uintptr_t)CONFIG_PHYS_RAM_BASE; kernel_map.size = (uintptr_t)(&_end) - (uintptr_t)(&_start);