On Fri 2024-09-06 17:39:46, zhang warden wrote: > Hi, John & Miroslav > > >> > >> Would it be possible to just use klp_transition_patch and implement the > >> logic just in using_show()? > > > > Yes, containing the logic to the sysfs file sounds a lot better. > > Maybe I can try to use the state of klp_transition_patch to update the function's state instead of changing code in klp_complete_transition? > > > > >> I have not thought through it completely but > >> klp_transition_patch is also an indicator that there is a transition going > >> on. It is set to NULL only after all func->transition are false. So if you > >> check that, you can assign -1 in using_show() immediately and then just > >> look at the top of func_stack. > > > > sysfs already has per-patch 'transition' and 'enabled' files so I don't > > like duplicating that information. > > > > The only thing missing is the patch stack order. How about a simple > > per-patch file which indicates that? > > > > /sys/kernel/livepatch/<patchA>/order => 1 > > /sys/kernel/livepatch/<patchB>/order => 2 > > > > The implementation should be trivial with the use of > > klp_for_each_patch() to count the patches. > > > I think this is the second solution. It seems that adding an > interface to patch level is an acceptable way. It seems to be the only acceptable idea at the moment. > And if patch order > is provided in /sys/kernel/livepatch/<patchA>/order, we should > make a user space tool to calculate the function that > is activate in the system. From my point to the original > problem, it is more look like a workaround. It is always a compromise between the complexity and the benefit. Upstream will accept only changes which are worth it. Here, the main problem is that you do not have coordinated developement and installation of livepatches. This is dangerous and you should not do it! Upstream will never support such a wild approach. You could get upstream some features which would make your life easier. But the features must be worth the effort. Best Regards, Petr
