On Thu, Sep 05, 2024 at 10:03:52PM +0800, zhang warden wrote: > >>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.
Thanks for the details, and sorry if I missed it before. This would have been helpful to have in the cover letter. But again I want to stress that livepatching should be done with care. Having different teams applying patches without coordination is not recommended. The teams' processes and/or tooling really need to be improved. > > 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. journalctl -b ? > If we use an user space program to maintain the information of patch order, > once the program is killed, the information is loss either. Store the state in a file in /var/run? -- Josh
