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
