Re: [PATCH v3 0/3] Convert vmcore to use an iov_iter
On Mon, Dec 13, 2021 at 02:39:24PM +, Matthew Wilcox (Oracle) wrote: > For some reason several people have been sending bad patches to fix > compiler warnings in vmcore recently. Here's how it should be done. > Compile-tested only on x86. As noted in the first patch, s390 should > take this conversion a bit further, but I'm not inclined to do that > work myself. A couple of notes: please, use iov_iter_count(i) instead of open-coding i->count. And there's a preexisting nastiness in read_vmcore() - generally, a fault halfway through the read() is treated as a short read, rather than -EFAULT... ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()
On 2021/12/31 17:22, Leizhen (ThunderTown) wrote:
>
>
> 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/vpoo...@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
>
> 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 + " can
> be used for adaptation without affecting other architectures.
I rethink it, the default value of default_nslabs is IO_TLB_DEFAULT_SIZE=64M.
The value of default_nslabs can only be changed by swiotlb_adjust_size() and
bootup command line option "swiotlb=". Currently, swiotlb_adjust_size() is
invoked only on x86, so I can just ignore it on arm64. Then, 64M is much
smaller than 256M, the first kernel works fine with the default 64M on arm64,
and I don't think the second kernel needs to grow to 256M. Therefore, I think
swiotlb_adjust_size() is probably a pseudo requirement for arm64.
So I will directly use 256M on arm64. If anyone gets into trouble, he/she can
add it back. Besides, there is also "crashkernel=Y,low" can be used.
>
>
> 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
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
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/vpoo...@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
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 + " 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
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
kexec fails with "locate_hole failed"
Kexec (version 2.0.20) fails to launch crashdump kernel with following error: > root@device:~# kexec --type zImage -p /boot/zImage > --append="root=/dev/mmcblk1p1 1 maxcpus=1 reset_devices" > syscall kexec_file_load not available. > Could not find a free area of memory of 0x1000 bytes... > locate_hole failed The kernel (version 4.1.52) was configured with CONFIG_KEXEC and CONFIG_SYSFS enabled. Additionally u-boot was updated to pass the kernel command line "crashkernel=96M@64M" to reserve RAM for the crash kernel. Can you please help to understand why kexec fails to find a free area of 0x1000 bytes if 96M should be available. Attaching "/proc/iomem" for reference: > root@device:~# cat /proc/iomem > 00905000-0091 : 905000.sram > 02008000-0200bfff : /soc/aips-bus@0200/spba-bus@0200/ecspi@02008000 > 0202-02023fff : /soc/aips-bus@0200/spba-bus@0200/serial@0202 > 02034000-02037fff : /soc/aips-bus@0200/spba-bus@0200/serial@02034000 > 0209c000-0209 : /soc/aips-bus@0200/gpio@0209c000 > 020a-020a3fff : /soc/aips-bus@0200/gpio@020a > 020a4000-020a7fff : /soc/aips-bus@0200/gpio@020a4000 > 020a8000-020abfff : /soc/aips-bus@0200/gpio@020a8000 > 020ac000-020a : /soc/aips-bus@0200/gpio@020ac000 > 020b8000-020bbfff : /soc/aips-bus@0200/kpp@020b8000 > 020bc000-020b : /soc/aips-bus@0200/wdog@020bc000 > 020c9000-020c9fff : /soc/aips-bus@0200/usbphy@020c9000 > 020ca000-020cafff : /soc/aips-bus@0200/usbphy@020ca000 > 020e-020e3fff : /soc/aips-bus@0200/iomuxc@020e > 020ec000-020e : /soc/aips-bus@0200/sdma@020ec000 > 020f-020f3fff : /soc/aips-bus@0200/pxp@020f > 020f8000-020fbfff : /soc/aips-bus@0200/lcdif@020f8000 > 020fc000-020f : /soc/aips-bus@0200/dcp@020fc000 > 02184000-021841ff : /soc/aips-bus@0210/usb@02184000 > 02184000-021841ff : /soc/aips-bus@0210/usb@02184000 > 02184800-021849ff : /soc/aips-bus@0210/usbmisc@02184800 > 02194000-02197fff : mmc1 > 021a-021a3fff : /soc/aips-bus@0210/i2c@021a > 021bc000-021b : /soc/aips-bus@0210/ocotp@021bc000 > 0220-02203fff : galcore register region > 02204000-02207fff : galcore register region > 0400-09ff : Crash kernel > 8000-8fff : System RAM > 80008000-8082633f : Kernel code > 8089-8094ee93 : Kernel data Thanks, Ros ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
