On 10/4/22 02:03, Sourabh Jain wrote:
On 30/09/22 21:06, Eric DeVolder wrote:
On 9/28/22 11:07, Borislav Petkov wrote:
On Tue, Sep 13, 2022 at 02:12:31PM -0500, Eric DeVolder wrote:
This topic was discussed previously https://lkml.org/lkml/2022/3/3/372.
Please do not use lkml.org to refer to lkml messages. We have a
perfectly fine archival system at lore.kernel.org. You simply do
https://lore.kernel.org/r/<Message-ID>
when you want to point to a previous mail.
ok, thanks for pointing that out to me.
David points out that terminology is tricky here due to differing behaviors.
And perhaps that is your point in asking for guidance text. It can be
complicated
Which means you need an explanation how to use this even more.
And why is CONFIG_CRASH_MAX_MEMORY_RANGES even a Kconfig item and not
something you discover from the hardware?
No, is the short answer.
Your help text talks about System RAM entries in /proc/iomem which means
that those entries are present somewhere in the kernel and you can read
them out and do the proper calculations dynamically instead of doing the
static CONFIG_NR_CPUS_DEFAULT + CONFIG_CRASH_MAX_MEMORY_RANGES thing.
The intent is to compute the max size buffer needed to contain a maximum populated elfcorehdr,
which is primarily based on the number of CPUs and memory regions. Thus far I (and others
involved) have not found a kernel method to determine the maximum number of memory regions
possible (if you are aware of one, please let me know!). Thus CONFIG_CRASH_MAX_MEMORY_RANGES was
born (rather borrowed from kexec-tools).
So no dynamic computation is possible, yet.
Hello Eric,
How about allocating buffer space for max program header possible in a elfcorehdr?
mage->elf_headers_sz = kbuf.memsz = PN_XNUM * sizeof(Elf64_Phdr);
PN_XNUM is part of linux/elf.h (include/uapi/linux/elf.h).
Refer below link for more details:
https://man7.org/linux/man-pages/man5/elf.5.html
Thanks,
Sourabh Jain
Well, that is an idea. I'm not sure it is the answer yet, but if I do compute
a value, then that value needs to be checked against PN_XNUM so it still results
in a valid elfcorehdr.
Thanks,
eric
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
