On Tue, 17 Dec 2024 10:24:42 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Tue, 17 Dec 2024 at 10:19, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > What *woiuld* have been an acceptable model is to actually modify the > > boot-time buffers in place, using actual real heuristics that look at > > whether a pointer was IN THE CODE SECTION OR THE STATIC DATA section > > of the previous boot. > > > > But you never did that. All this delta code has always been complete > > and utter garbage, and complete hacks. > > Actually, I think the proper model isn't even that "modify boot time > buffers in place" thing. > > The proper model was probably always to just do the "give the raw > data, and analyze the previous boot data in user mode". Don't do > "delta between old and new kernel", print out the actual KASLR base of > the old kernel, and let user mode figure it out. Because user mode may > actually have the old and different vmlinux image too - something that > kernel mode *never* has. I already support this somewhat, as the text_delta (and data_delta) are presented in the tracefs directory so that trace-cmd can parse it. For my use case, this would work, as we are extracting the raw data and need to do most the processing in user space anyway. I could have it export the KASLR offset of the previous boot and then trace-cmd should be able to handle it fine if the events and kallsyms of the previous boot are all saved. It could easily put things back together, including modules and dynamic events. This will just make it useless for those that want to use the tracefs directly. -- Steve
