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. > > Maybe we'd want to backport 1,2,3, but not sure if we consider this critical > enough. > > -- > Cheers, > > David / dhildenb >
