On Thu, May 9, 2024 at 1:20 PM Josh Poimboeuf [off-list ref] wrote:

On Thu, May 09, 2024 at 10:17:43AM +0800, Yafang Shao wrote:

quoted

On Wed, May 8, 2024 at 3:03 PM Josh Poimboeuf [off-list ref] wrote:

quoted

On Wed, May 08, 2024 at 02:01:29PM +0800, Yafang Shao wrote:

quoted

On Wed, May 8, 2024 at 1:16 PM Josh Poimboeuf [off-list ref] wrote:

quoted

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