Re: [PATCH v1 07/11] fs/proc/vmcore: introduce PROC_VMCORE_DEVICE_RAM to detect device RAM ranges in 2nd kernel

[David Hildenbrand]

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
> ============

So the three changes you did are

(a) Remove the config option but select/depend on them.

(b) Remove the "depends on PROC_VMCORE" from PROC_VMCORE_DEVICE_RAM,
    and the "if PROC_VMCORE" from s390.

(c) Remove the PROVIDE_PROC_VMCORE_DEVICE_RAM


Regarding (a), that doesn't work. If you select a config option that 
doesn't exist, it is silently dropped. It's always treated as if it 
wouldn't be set.

Regarding (b), I think that's an anti-pattern (having config options 
enabled that are completely ineffective) and I don't see a benefit 
dropping them.

Regarding (c), it would mean that s390x unconditionally includes that 
code even if virtio-mem is not configured in.

So while we could drop PROVIDE_PROC_VMCORE_DEVICE_RAM -- (c), it would 
that we end up including code in configurations that don't possibly need 
it. That's why I included that part.

> ======= config items extracted from this patchset====
> 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
>
> config VIRTIO_MEM
> 	depends on X86_64 || ARM64 || RISCV
>           ~~~~~ I don't get why VIRTIO_MEM dones't depend on S390 if
>                 s390 need PROC_VMCORE_DEVICE_RAM.

This series depends on s390 support for virtio-mem, which just went 
upstream.

See

commit 38968bcdcc1d46f2fdcd3a72599d5193bf8baf84
Author: David Hildenbrand <david@xxxxxxxxxx>
Date:   Fri Oct 25 16:14:49 2024 +0200

    virtio-mem: s390 support


>          ......
>          select PROVIDE_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE
>
> config S390
>          select NEED_PROC_VMCORE_DEVICE_RAM if PROC_VMCORE
> =================================================

Thanks for having a look!

--
Cheers,

David / dhildenb