linux-kernel - Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <207b6257-22bc-c9fe-6206-4096d8e0d276@huawei.com>
Date:   Fri, 31 Dec 2021 17:22:56 +0800
From:   "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, <x86@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, <linux-kernel@...r.kernel.org>,
        Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
        Vivek Goyal <vgoyal@...hat.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        <kexec@...ts.infradead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        <devicetree@...r.kernel.org>, "Jonathan Corbet" <corbet@....net>,
        <linux-doc@...r.kernel.org>, Randy Dunlap <rdunlap@...radead.org>,
        Feng Zhou <zhoufeng.zf@...edance.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Chen Zhou <dingguo.cz@...group.com>,
        "John Donnelly" <John.p.donnelly@...cle.com>
Subject: Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()



On 2021/12/30 19:08, Leizhen (ThunderTown) wrote:
> 
> 
> On 2021/12/30 18:40, Borislav Petkov wrote:
>> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>>
>>> Hi, Dave, Baoquan, Borislav:
>>>   What do you think about the introduction of parse_crashkernel_high_low()? If everyone
>>> doesn't object, I'll bring it to the next version. But I'll make some adjustments to the
>>> patches, see below. If there's any objection, I still strongly recommend removing the
>>> parameters "system_ram" and "crash_base" of parse_crashkernel_{high,low}().
>>>
>>> How about splitting __parse_crashkernel() into two parts? One for parsing
>>> "crashkernel=X[@offset]", another one for parsing "crashkernel=X,{high,low}" and other
>>> suffixes in the future. So the parameter requirements are clear at the lowest level.
>>
>> First of all, please do not top post!
>>
>> Now, I already explained to you what I'd like to see:
>>
>> https://lore.kernel.org/r/Ycs3kpZD/vpoo1AX@zn.tnic
>>
>> yet you still don't get it.
>>
>> So let me make myself clear: in its current form, this is not really an
>> improvement so for all x86 changes:
>>
>> NAKed-by: Borislav Petkov <bp@...e.de>

Hi Borislav:
  I'm sorry to bother you again. Do you mind if I make the following changes?
I can't stand so many comments appearing twice. Even if the size needs to be
changed in the future, mode "low_size = CRASH_LOW_SIZE_MIN + <increment>" can
be used for adaptation without affecting other architectures.


diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e04f5e6eb33f453..da485ee51a9929e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -428,16 +428,7 @@ static int __init reserve_crashkernel_low(void)
        /* crashkernel=Y,low */
        ret = parse_crashkernel_low(boot_command_line, low_mem_limit, &low_size, &base);
        if (ret) {
-               /*
-                * two parts from kernel/dma/swiotlb.c:
-                * -swiotlb size: user-specified with swiotlb= or default.
-                *
-                * -swiotlb overflow buffer: now hardcoded to 32k. We round it
-                * to 8M for other buffers that may need to stay low too. Also
-                * make sure we allocate enough extra low memory so that we
-                * don't run out of DMA buffers for 32-bit devices.
-                */
-               low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20);
+               low_size = CRASH_LOW_SIZE_MIN;
        } else {
                /* passed with crashkernel=0,low ? */
                if (!low_size)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index de62a722431e7db..c85b15814312b7e 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -69,6 +69,17 @@ phys_addr_t paddr_vmcoreinfo_note(void);
 #define VMCOREINFO_CONFIG(name) \
        vmcoreinfo_append_str("CONFIG_%s=y\n", #name)

+/*
+ * two parts from kernel/dma/swiotlb.c:
+ * -swiotlb size: user-specified with swiotlb= or default.
+ *
+ * -swiotlb overflow buffer: now hardcoded to 32k. We round it
+ * to 8M for other buffers that may need to stay low too. Also
+ * make sure we allocate enough extra low memory so that we
+ * don't run out of DMA buffers for 32-bit devices.
+ */
+#define CRASH_LOW_SIZE_MIN     max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20)
+
 extern unsigned char *vmcoreinfo_data;
 extern size_t vmcoreinfo_size;
 extern u32 *vmcoreinfo_note;


>>
> 
> OK, thanks for your immediate reply, so I can take less detours.
> 

-- 
Regards,
  Zhen Lei