[PATCH v1 01/11] fs/proc/vmcore: convert vmcore_cb_lock into vmcore_mutex
David Hildenbrand
david at redhat.com
Fri Nov 15 02:03:40 PST 2024
On 15.11.24 10:30, Baoquan He wrote:
> On 10/25/24 at 05:11pm, David Hildenbrand wrote:
>> We want to protect vmcore modifications from concurrent opening of
>> the vmcore, and also serialize vmcore modiciations. Let's convert the
>
>
>> spinlock into a mutex, because some of the operations we'll be
>> protecting might sleep (e.g., memory allocations) and might take a bit
>> longer.
>
> Could you elaborate this a little further. E.g the concurrent opening of
> vmcore is spot before this patchset or have been seen, and in which place
> the memory allocation is spot. Asking this becasue I'd like to learn and
> make clear if this is a existing issue and need be back ported into our
> old RHEL distros. Thanks in advance.
It's a preparation for the other patches, that do what is described here:
a) We can currently modify the vmcore after it was opened. This can
happen if the vmcoredd is added after the vmcore was loaded. Similar
things will happen with the PROC_VMCORE_DEVICE_RAM extension.
b) To handle it cleanly we need to protect the modifications against
concurrent opening. And the modifcations end up allocating memory and
cannot easily take the spinlock.
So far a spinlock was sufficient, now a mutex is required.
Maybe we'd want to backport 1,2,3, but not sure if we consider this
critical enough.
--
Cheers,
David / dhildenb
More information about the kexec
mailing list