On 8/4/25 13:54, Michal Hocko wrote: > On Wed 30-07-25 16:04:28, David Hildenbrand wrote: >> On 30.07.25 15:57, Eugen Hristev wrote: > [...] >>> Yes, registering after is also an option. Initially this is how I >>> designed the kmemdump API, I also had in mind to add a flag, but, after >>> discussing with Thomas Gleixner, he came up with the macro wrapper idea >>> here: >>> https://lore.kernel.org/lkml/87ikkzpcup.ffs@tglx/ >>> Do you think we can continue that discussion , or maybe start it here ? >> >> Yeah, I don't like that, but I can see how we ended up here. >> >> I also don't quite like the idea that we must encode here what to include in >> a dump and what not ... >> >> For the vmcore we construct it at runtime in crash_save_vmcoreinfo_init(), >> where we e.g., have >> >> VMCOREINFO_STRUCT_SIZE(pglist_data); >> >> Could we similar have some place where we construct what to dump similarly, >> just not using the current values, but the memory ranges? > > All those symbols are part of kallsyms, right? Can we just use kallsyms > infrastructure and a list of symbols to get what we need from there? > > In other words the list of symbols to be completely external to the code > that is defining them? Some static symbols are indeed part of kallsyms. But some symbols are not exported, for example patch 20/29, where printk related symbols are not to be exported. Another example is with static variables, like in patch 17/29 , not exported as symbols, but required for the dump. Dynamic memory regions are not have to also be considered, have a look for example at patch 23/29 , where dynamically allocated memory needs to be registered. Do you think that I should move all kallsyms related symbols annotation into a separate place and keep it for the static/dynamic regions in place ? Thanks for looking into my patch, Eugen
