linux-kernel - Re: [PATCH] MIPS: Refactor early_parse

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]

Date:   Fri, 25 Feb 2022 10:08:43 +0800
From:   Tiezhu Yang <yangtiezhu@...ngson.cn>
To:     Youling Tang <tangyouling@...ngson.cn>
Cc:     Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Xuefeng Li <lixuefeng@...ngson.cn>, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MIPS: Refactor early_parse_mem() to fix mem= parameter



On 02/25/2022 09:12 AM, Youling Tang wrote:
> Hi, Tiezhu
>
> On 02/24/2022 08:52 PM, Tiezhu Yang wrote:
>> According to Documentation/admin-guide/kernel-parameters.txt,
>> the kernel command-line parameter mem= means "Force usage of
>> a specific amount of memory", but when add "mem=3G" to the
>> command-line, kernel boot hangs in sparse_init().
>>
>> This commit is similar with the implementation of the other
>> archs such as arm64, powerpc and riscv, refactor the function
>> early_parse_mem() and then use memblock_enforce_memory_limit()
>> to limit the memory size.
>>
>> With this patch, when add "mem=3G" to the command-line, the
>> kernel boots successfully, we can see the following messages:
>>
>>    [    0.000000] Memory limited to 3072MB
>>    ...
>>    [    0.000000] Memory: 2991952K/3145728K available (...)
>>
>> After login, the output of free command is consistent with the
>> above log.
>>
>> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
>> ---
>>   arch/mips/kernel/setup.c | 25 ++++++++-----------------
>>   1 file changed, 8 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index f979adf..2917412 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -339,27 +339,15 @@ static void __init bootmem_init(void)
>>   #endif    /* CONFIG_SGI_IP27 */
>>     static int usermem __initdata;
>> +static phys_addr_t memory_limit;
>>     static int __init early_parse_mem(char *p)
>>   {
>> -    phys_addr_t start, size;
>> -
>> -    /*
>> -     * If a user specifies memory size, we
>> -     * blow away any automatically generated
>> -     * size.
>> -     */
>> -    if (usermem == 0) {
>> -        usermem = 1;
>> -        memblock_remove(memblock_start_of_DRAM(),
>> -            memblock_end_of_DRAM() - memblock_start_of_DRAM());
>> -    }
>> -    start = 0;
>> -    size = memparse(p, &p);
>> -    if (*p == '@')
>> -        start = memparse(p + 1, &p);
>> +    if (!p)
>> +        return 1;
>>   -    memblock_add(start, size);
>> +    memory_limit = memparse(p, &p) & PAGE_MASK;
>> +    pr_notice("Memory limited to %lldMB\n", memory_limit >> 20);
>>         return 0;
>
> After applying this patch, my guess is that the kdump operation will fail.
>
> In the MIPS architecture, when the kdump operation is performed, a
> "mem=YM@XM" parameter will be added to the capture kernel (added by
> kexec-tools), indicating that the available memory range of the
> capture kernel is [X, X+Y).
>
> After the "mem" parameter is changed to the above, there will be only
> a similar parsing function like "mem=3G", and the type like
> "mem=128M@64M" cannot be correctly parsed.

Hi Youling,

Don't worry, it is another issue, I will take that into account
once this patch is applied.

This commit is the first step to fix the issue about mem=limit,
I think it is possible to support mem=limit@...e and I will do
that later.

Thanks,
Tiezhu

>
> Thanks,
> Youling.
>>   }
>> @@ -633,6 +621,9 @@ static void __init arch_mem_init(char **cmdline_p)
>>         parse_early_param();
>>   +    /* Limit the memory size via mem= command-line parameter */
>> +    memblock_enforce_memory_limit(memory_limit);
>> +
>>       if (usermem)
>>           pr_info("User-defined physical RAM map overwrite\n");
>>