On 20.11.24 15:05, Baoquan He wrote:
On 11/20/24 at 11:48am, David Hildenbrand wrote:
On 20.11.24 11:13, Baoquan He wrote:
On 10/25/24 at 05:11pm, David Hildenbrand wrote:
s390 allocates+prepares the elfcore hdr in the dump (2nd) kernel, not in
the crashed kernel.
RAM provided by memory devices such as virtio-mem can only be detected
using the device driver; when vmcore_init() is called, these device
drivers are usually not loaded yet, or the devices did not get probed
yet. Consequently, on s390 these RAM ranges will not be included in
the crash dump, which makes the dump partially corrupt and is
unfortunate.
Instead of deferring the vmcore_init() call, to an (unclear?) later point,
let's reuse the vmcore_cb infrastructure to obtain device RAM ranges as
the device drivers probe the device and get access to this information.
Then, we'll add these ranges to the vmcore, adding more PT_LOAD
entries and updating the offsets+vmcore size.
Use Kconfig tricks to include this code automatically only if (a) there is
a device driver compiled that implements the callback
(PROVIDE_PROC_VMCORE_DEVICE_RAM) and; (b) the architecture actually needs
this information (NEED_PROC_VMCORE_DEVICE_RAM).
The current target use case is s390, which only creates an elf64
elfcore, so focusing on elf64 is sufficient.
Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
---
fs/proc/Kconfig | 25 ++++++
fs/proc/vmcore.c | 156 +++++++++++++++++++++++++++++++++++++
include/linux/crash_dump.h | 9 +++
3 files changed, 190 insertions(+)
diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
index d80a1431ef7b..1e11de5f9380 100644
--- a/fs/proc/Kconfig
+++ b/fs/proc/Kconfig
@@ -61,6 +61,31 @@ config PROC_VMCORE_DEVICE_DUMP
as ELF notes to /proc/vmcore. You can still disable device
dump using the kernel command line option 'novmcoredd'.
+config PROVIDE_PROC_VMCORE_DEVICE_RAM
+ def_bool n
+
+config NEED_PROC_VMCORE_DEVICE_RAM
+ def_bool n
+
+config PROC_VMCORE_DEVICE_RAM
+ def_bool y
+ depends on PROC_VMCORE
+ depends on NEED_PROC_VMCORE_DEVICE_RAM
+ depends on PROVIDE_PROC_VMCORE_DEVICE_RAM
Kconfig item is always a thing I need learn to master.
Yes, it's usually a struggle to get it right. It took me a couple of
iterations to get to this point :)
When I checked
this part, I have to write them down to deliberate. I am wondering if
below 'simple version' works too and more understandable. Please help
point out what I have missed.
===========simple version======
config PROC_VMCORE_DEVICE_RAM
def_bool y
depends on PROC_VMCORE && VIRTIO_MEM
depends on NEED_PROC_VMCORE_DEVICE_RAM
config S390
select NEED_PROC_VMCORE_DEVICE_RAM
============
Sorry, things written down didn't correctly reflect them in my mind.
===========simple version======
fs/proc/Kconfig:
config PROC_VMCORE_DEVICE_RAM
def_bool y
depends on PROC_VMCORE && VIRTIO_MEM
depends on NEED_PROC_VMCORE_DEVICE_RAM
arch/s390/Kconfig:
config NEED_PROC_VMCORE_DEVICE_RAM
def y
==================================
That would work, but I don't completely like it.
(a) I want s390x to select NEED_PROC_VMCORE_DEVICE_RAM instead. Staring
at a bunch of similar cases (git grep "config NEED" | grep Kconfig, git
grep "config ARCH_WANTS" | grep Kconfig), "select" is the common way to
do it.
So unless there is a pretty good reason, I'll keep
NEED_PROC_VMCORE_DEVICE_RAM as is.
(b) In the context of this patch, "depends on VIRTIO_MEM" does not make
sense. We could have an intermediate:
config PROC_VMCORE_DEVICE_RAM
def_bool n
depends on PROC_VMCORE
depends on NEED_PROC_VMCORE_DEVICE_RAM
And change that with VIRTIO_MEM support in the relevant patch.
I faintly remember that we try avoiding such dependencies and prefer
selecting Kconfigs instead. Just look at the SPLIT_PTE_PTLOCKS mess we
still have to clean up. But as we don't expect that many providers for
now, I don't care.
Thanks!
--
Cheers,
David / dhildenb
