Patch "mips: Fix incorrect max_low_pfn adjustment" has been added to the 5.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    mips: Fix incorrect max_low_pfn adjustment

to the 5.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mips-fix-incorrect-max_low_pfn-adjustment.patch
and it can be found in the queue-5.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit ade38cadfd138a38d7184d399af0d19293e202d6
Author: Serge Semin <fancer.lancer@xxxxxxxxx>
Date:   Sat Dec 2 14:14:19 2023 +0300

    mips: Fix incorrect max_low_pfn adjustment
    
    [ Upstream commit 0f5cc249ff73552d3bd864e62f85841dafaa107d ]
    
    max_low_pfn variable is incorrectly adjusted if the kernel is built with
    high memory support and the later is detected in a running system, so the
    memory which actually can be directly mapped is getting into the highmem
    zone. See the ZONE_NORMAL range on my MIPS32r5 system:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x0000000007ffffff]
    >   HighMem  [mem 0x0000000008000000-0x000000020fffffff]
    
    while the zones are supposed to look as follows:
    
    > Zone ranges:
    >   DMA      [mem 0x0000000000000000-0x0000000000ffffff]
    >   Normal   [mem 0x0000000001000000-0x000000001fffffff]
    >   HighMem  [mem 0x0000000020000000-0x000000020fffffff]
    
    Even though the physical memory within the range [0x08000000;0x20000000]
    belongs to MMIO on our system, we don't really want it to be considered as
    high memory since on MIPS32 that range still can be directly mapped.
    
    Note there might be other problems caused by the max_low_pfn variable
    misconfiguration. For instance high_memory variable is initialize with
    virtual address corresponding to the max_low_pfn PFN, and by design it
    must define the upper bound on direct map memory, then end of the normal
    zone. That in its turn potentially may cause problems in accessing the
    memory by means of the /dev/mem and /dev/kmem devices.
    
    Let's fix the discovered misconfiguration then. It turns out the commit
    a94e4f24ec83 ("MIPS: init: Drop boot_mem_map") didn't introduce the
    max_low_pfn adjustment quite correct. If the kernel is built with high
    memory support and the system is equipped with high memory, the
    max_low_pfn variable will need to be initialized with PFN of the most
    upper directly reachable memory address so the zone normal would be
    correctly setup. On MIPS that PFN corresponds to PFN_DOWN(HIGHMEM_START).
    If the system is built with no high memory support and one is detected in
    the running system, we'll just need to adjust the max_pfn variable to
    discard the found high memory from the system and leave the max_low_pfn as
    is, since the later will be less than PFN_DOWN(HIGHMEM_START) anyway by
    design of the for_each_memblock() loop performed a bit early in the
    bootmem_init() method.
    
    Fixes: a94e4f24ec83 ("MIPS: init: Drop boot_mem_map")
    Signed-off-by: Serge Semin <fancer.lancer@xxxxxxxxx>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@xxxxxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 1c4114f8f9aa..0419629aee60 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -362,11 +362,11 @@ static void __init bootmem_init(void)
 		panic("Incorrect memory mapping !!!");
 
 	if (max_pfn > PFN_DOWN(HIGHMEM_START)) {
+		max_low_pfn = PFN_DOWN(HIGHMEM_START);
 #ifdef CONFIG_HIGHMEM
-		highstart_pfn = PFN_DOWN(HIGHMEM_START);
+		highstart_pfn = max_low_pfn;
 		highend_pfn = max_pfn;
 #else
-		max_low_pfn = PFN_DOWN(HIGHMEM_START);
 		max_pfn = max_low_pfn;
 #endif
 	}




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux