On Tue, 9 Nov 2021 at 14:40, David Hildenbrand <david@xxxxxxxxxx> wrote:
On 09.11.21 04:59, Dave Young wrote:
> Hi Andrew,
> On 11/08/21 at 06:31pm, Andrew Morton wrote:
>> From: David Hildenbrand <david@xxxxxxxxxx>
>> Subject: proc/vmcore: convert oldmem_pfn_is_ram callback to more generic vmcore callbacks
>>
>> Let's support multiple registered callbacks, making sure that registering
>> vmcore callbacks cannot fail. Make the callback return a bool instead of
>> an int, handling how to deal with errors internally. Drop unused
>> HAVE_OLDMEM_PFN_IS_RAM.
>>
>> We soon want to make use of this infrastructure from other drivers:
>> virtio-mem, registering one callback for each virtio-mem device, to
>> prevent reading unplugged virtio-mem memory.
>>
>> Handle it via a generic vmcore_cb structure, prepared for future
>> extensions: for example, once we support virtio-mem on s390x where the
>> vmcore is completely constructed in the second kernel, we want to detect
>> and add plugged virtio-mem memory ranges to the vmcore in order for them
>> to get dumped properly.
>>
>> Handle corner cases that are unexpected and shouldn't happen in sane
>> setups: registering a callback after the vmcore has already been opened
>> (warn only) and unregistering a callback after the vmcore has already been
>> opened (warn and essentially read only zeroes from that point on).
>
> This is a nice improvement, thanks David. But I did not get time to
> review it yet. The overall idea is good, I would prefer to hold on the
> patches for some time and waiting for more review.
>
> Sorry for jumping in late.
I really want this in v5.16. Please see the comment in
https://lkml.kernel.org/r/20211006122709.27885-1-david@xxxxxxxxxx
Can we just fix any fallout (if any) as usual after the merge window?
Hi David, sounds good to me if there are no other objections.
As we discussed offline in another thread, we can address the issues later if we have, eg. measuring the dump performance etc.
Thanks
Dave
--
Thanks,
David / dhildenb
