On Thu, May 9, 2024 at 1:20 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Thu, May 09, 2024 at 10:17:43AM +0800, Yafang Shao wrote: > > On Wed, May 8, 2024 at 3:03 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > > On Wed, May 08, 2024 at 02:01:29PM +0800, Yafang Shao wrote: > > > > On Wed, May 8, 2024 at 1:16 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > If klp_patch.replace is set on the new patch then it will replace all > > > > > previous patches. > > > > > > > > A scenario exists wherein a user could simultaneously disable a loaded > > > > livepatch, potentially resulting in it not being replaced by the new > > > > patch. While theoretical, this possibility is not entirely > > > > implausible. > > > > > > Why does it matter whether it was replaced, or was disabled beforehand? > > > Either way the end result is the same. > > > > When users disable the livepatch, the corresponding kernel module may > > sometimes be removed, while other times it remains intact. This > > inconsistency has the potential to confuse users. > > I'm afraid I don't understand. Can you give an example scenario? > As previously mentioned, this scenario may occur if user-space tools remove all pertinent kernel modules from /sys/livepatch/* while a user attempts to load a new atomic-replace livepatch. For instance: User-A User-B echo 0 > /sys/livepatch/A/enable insmod atomic-replace-patch.ko >From User-A's viewpoint, the A.ko module might sometimes be removed, while at other times it remains intact. The reason is that User-B removed a module that he shouldn't remove. -- Regards Yafang
