linux-kernel - Re: [PATCH] LoongArch: mm: Set max_pfn with the PFN of the last page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3a04b960-e3ad-0656-d69d-6e85079d305a@loongson.cn>
Date: Wed, 5 Mar 2025 09:33:09 +0800
From: bibo mao <maobibo@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: WANG Xuerui <kernel@...0n.name>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] LoongArch: mm: Set max_pfn with the PFN of the last page



On 2025/3/4 下午8:25, Huacai Chen wrote:
> Hi, Bibo,
> 
> On Tue, Mar 4, 2025 at 7:27 PM Bibo Mao <maobibo@...ngson.cn> wrote:
>>
>> The current max_pfn equals to zero. In this case, it caused users cannot
>> get some page information through /proc such as kpagecount. The following
>> message is displayed by stress-ng test suite with the command
>> "stress-ng --verbose --physpage 1 -t 1".
>>
>>   # stress-ng --verbose --physpage 1 -t 1
>>   stress-ng: error: [1691] physpage: cannot read page count for address 0x134ac000 in /proc/kpagecount, errno=22 (Invalid argument)
>>   stress-ng: error: [1691] physpage: cannot read page count for address 0x7ffff207c3a8 in /proc/kpagecount, errno=22 (Invalid argument)
>>   stress-ng: error: [1691] physpage: cannot read page count for address 0x134b0000 in /proc/kpagecount, errno=22 (Invalid argument)
>>   ...
>>
>> After applying this patch, the kernel can pass the test.
>>   # stress-ng --verbose --physpage 1 -t 1
>>   stress-ng: debug: [1701] physpage: [1701] started (instance 0 on CPU 3)
>>   stress-ng: debug: [1701] physpage: [1701] exited (instance 0 on CPU 3)
>>   stress-ng: debug: [1700] physpage: [1701] terminated (success)
>>
>> Signed-off-by: Bibo Mao <maobibo@...ngson.cn>
> I think this patch are mainly fix commit
> ff6c3d81f2e86b63a3a530683f89ef39 ("NUMA: optimize detection of memory
> with no node id assigned by firmware"). So it is better to add a
> Fixes: tag and Cc stable.
> 
> And the patch itself can be improved. there are three cases of
> calculating max_low_pfn:
> ACPI with NUMA, handled in numa.c
> ACPI without NUMA, handled in mem.c
> FDT, handled in setup.c
> 
> You have missed the 2nd case. The simplest way is add "max_pfn =
> max_low_pfn" at the beginning of arch_mem_init() because all cases can
> be handled here.
yes, that is actually one problem:)  Will do this simply in 
arch_mem_init() in next patch.

Regards
Bibo Mao
> 
> Huacai
> 
>> ---
>>   arch/loongarch/kernel/numa.c  | 2 +-
>>   arch/loongarch/kernel/setup.c | 2 +-
>>   2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/loongarch/kernel/numa.c b/arch/loongarch/kernel/numa.c
>> index 84fe7f854820..002dbe62b329 100644
>> --- a/arch/loongarch/kernel/numa.c
>> +++ b/arch/loongarch/kernel/numa.c
>> @@ -356,7 +356,7 @@ int __init init_numa_memory(void)
>>                  node_mem_init(node);
>>                  node_set_online(node);
>>          }
>> -       max_low_pfn = PHYS_PFN(memblock_end_of_DRAM());
>> +       max_low_pfn = max_pfn = PHYS_PFN(memblock_end_of_DRAM());
>>
>>          setup_nr_node_ids();
>>          loongson_sysconf.nr_nodes = nr_node_ids;
>> diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
>> index edcfdfcad7d2..ab8c9336d8f5 100644
>> --- a/arch/loongarch/kernel/setup.c
>> +++ b/arch/loongarch/kernel/setup.c
>> @@ -294,7 +294,7 @@ static void __init fdt_setup(void)
>>          early_init_dt_scan(fdt_pointer, __pa(fdt_pointer));
>>          early_init_fdt_reserve_self();
>>
>> -       max_low_pfn = PFN_PHYS(memblock_end_of_DRAM());
>> +       max_low_pfn = max_pfn = PFN_PHYS(memblock_end_of_DRAM());
>>   #endif
>>   }
>>
>> --
>> 2.39.3
>>