Hi, Josh. > Most of this information is already available in sysfs, with the > exception of patch stacking order. > Well, this is the problem my patch want to fix. But my patch is more simpler, it just shows the stack top of the target function, which is the only thing users care. > > We want patches that fix real world, tangible problems, not theoretical > problems that it *might* solve for a hypothetical user. > > What is the motiviation behind this patch? What real world problem does > it fix for you, or an actual user? Here I can give you an example as I previous described: >>Here I can give you an example. We are going to fix a problem of io_uring. Our team made a livepatch of io_sq_offload_create. This livepatch module is deployed to some running servers. Then, another team make some change to the same function and deployed it to the same cluster. Finally, they found that there are some livepatch module modifying the same function io_sq_offload_create. But none of them can tell which version of io_sq_offload_create is now exactly running in the system. We can only use crash to debug /proc/kcore to see if we can get more information from the kcore. If livepatch can tell which version of the function is now running or going to run, it will be very useful. >>>>>> What's more, the scenario we easily face is that for the confidential environment, the system maintenance mainly depends on SREs. Different team may do bug fix or performance optimization to kernel function. Here usually some SREs comes to me and ask me how to make sure which version is now actually active because tow teams make tow livepatch modules, both of them make changes to one function. He wants to know if his system is under risk, he want the system run the right version of the function because one module is a bug fix and the other is just a performance optimization module, at this time, the bug fix version is much more important. dmesg is too long, he find it hard to find out the patch order from dmesg. With this patch, he can just cat /sys/kernel/livepatch/<module>/<object>/<function>/using and get his answer. > Have you considered other solutions, > like more organized patch management in user space? User space solutions seems unreliable. What we need is just the enabling version of target function. The order of livepatch module enable mainly from dmesg, which is easily flush away or being cleaned. If we use an user space program to maintain the information of patch order, once the program is killed, the information is loss either. Neither of the previous user space solutions seems reliable. Only kernel space will no one can change it. And it is the most accurate.
