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
| ||
|
Date: Tue, 1 Mar 2022 16:31:46 +0200 From: Mike Rapoport <rppt@...nel.org> To: Tiezhu Yang <yangtiezhu@...ngson.cn> Cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Andrew Morton <akpm@...ux-foundation.org>, Xuefeng Li <lixuefeng@...ngson.cn>, linux-mips@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH v4 0/4] MIPS: Modify mem= and memmap= parameter On Tue, Mar 01, 2022 at 07:51:23PM +0800, Tiezhu Yang wrote: > > > On 03/01/2022 05:55 PM, Mike Rapoport wrote: > > Hi, > > > > On Tue, Mar 01, 2022 at 12:28:57PM +0800, Tiezhu Yang wrote: > > > In the current code, the kernel command-line parameter mem= and memmap= > > > can not work well on MIPS, this patchset refactors the related code to > > > fix them. > > > > > > For kdump on MIPS, if the users want to limit the memory region for the > > > capture kernel to avoid corrupting the memory image of the panic kernel, > > > use the parameter memmap=limit@...e is the proper way, I will submit a > > > patch to use memmap=limit@...e for kexec-tools after this patchset is > > > applied. > > > > Sorry, apparently I misread the prevoius version. > > What's wrong with the current implementation of mem=limit@...e for the > > kdump case? > > In the current code, without this patchset, kernel boot hangs when add > mem=3G, mem=3G@64M or memmap=3G@64M to the command-line, it means that > the parameter mem= and memmap= have bug on mips. I can see how mem=3G may be wrong when the memory does not start at 0, but it seems to do the right thing of mem=3G@.... Do you see system hangs with mem=3G@...? Do you have the logs before the hang? As for memmap= option, it does not specify the memory map but rather alters the memory map passed by the firmware. Particularity in MIPS implementation it allows to add a single range of available or reserved memory. AFAIU, for the kdump use-case mem=X@Y should suffice. > Thanks, > Tiezhu > > > > > > v4: Fix some build warnings reported by kernel test robot > > > > > > v3: Modify patch #3 to maintain compatibility for memmap=limit{$,#,!}base, > > > commented by Mike Rapoport, thank you > > > > > > v2: Add some new patches to support memmap=limit@...e > > > > > > Tiezhu Yang (4): > > > MIPS: Refactor early_parse_mem() to fix mem= parameter > > > memblock: Introduce memblock_mem_range_remove_map() > > > MIPS: Refactor early_parse_memmap() to fix memmap= parameter > > > MIPS: Remove not used variable usermem > > > > > > arch/mips/kernel/setup.c | 69 ++++++++++++++++++++++-------------------------- > > > include/linux/memblock.h | 1 + > > > mm/memblock.c | 9 +++++-- > > > 3 files changed, 40 insertions(+), 39 deletions(-) > > > > > > -- > > > 2.1.0 > > > > > > -- Sincerely yours, Mike.
Powered by blists - more mailing lists