On 20.11.24 09:16, Baoquan He wrote:
On 11/15/24 at 11:03am, David Hildenbrand wrote:
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.
I see, as we talked in patch 2 sub-thread, these information are very
valuable to help people get the background information when they read
code. Let's put it in patch log. Thanks.
I'll extend the description if that helps, thanks!
--
Cheers,
David / dhildenb
