Re: [PATCH v3 3/7] livepatch: Support scoped atomic replace using replace_set

[Joe Lawrence <joe.lawrence@redhat.com>]

On 6/22/26 11:08 PM, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 1:27 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>>
>> On Thu, Jun 18, 2026 at 03:03:56PM +0200, Petr Mladek wrote:
>>> On Wed 2026-06-17 16:06:59, Joe Lawrence wrote:
>>>> On Wed, Jun 17, 2026 at 03:52:27PM +0200, Petr Mladek wrote:
>>>>> On Tue 2026-06-16 16:15:17, Joe Lawrence wrote:
>>>>
>>>> [ ... snip ... ]
>>>>
>>>> I can read replace_sets two ways:
>>>>
>>>>   1. Positional: { set [, eviction_set ...] } where the first element is
>>>>      the patch's own set and the rest are evicted on load.
>>>>
>>>>   2. Flat: the patch belongs to every listed set equally.  But then how
>>>>      could klp-2b load into set 2 without replacing the entire
>>>>      cumulative klp-2a that also occupies it?
>>>
>>> I understand it a 3rd way (similar to Yafang?) ;-)
>>>
>>>       3. Set: the patch replaces the given set of replace_sets.
>>>        Where klp-2a is a cumulative livepatch for two
>>>        replace_sets: 1,2. And klp-2b hotfix would need to
>>>        use a new replace_set, .e.g. 3.
>>>
>>>        I see "replace_set" as a set of modifications (functions,
>>>        shadow variables, and callbacks) which is supposed to
>>>        replace/update/downgrade the same "replace_set".
>>>
>>> It would have the following consequences:
>>> -----------------------------------------
>>>
>>> First, any newer cumulative livepatch would need to replace all
>>> older hotfixes. Let's extend your example:
>>>
>>>    Wed: klp-1a: cumulative    (replace_sets={1})
>>>    Thu: klp-1b: hotfix        (replace_sets={2})     <- coexists with klp-1a
>>>    Fri: klp-1c: hotfix v2     (replace_sets={2})     <- replaces klp-1b (same set)
>>>    Mon: klp-2a: cumulative    (replace_sets={1,2})   <- replaces klp-1a AND wipes klp-1c
>>>    Tue: klp-2b: hotfix        (replace_sets={3})     <- coexists with klp-2a
>>>    Fri: klp-3a: cumulative    (replace_sets={1,2,3}) <- replaces klp-2a AND wipes klp-2b
>>>    Fri: klp-4a: cumulative    (replace_sets={1,2,3}) <- replaces klp-3a
>>>    Fri: klp-5a: cumulative    (replace_sets={1,2,3}) <- replaces klp-4a
>>>
>>
>> This is making sense so far: hotfixes introduce new replace_set(s),
>> subsequent cumulatives replace all sets that came before it.
>>
>> Quick question for you or Yafang based on his thoughts on my other reply:
>>
>>> [Yafang] I support the flat mode approach. The hotfix should be assigned to a
>>> set that is not currently in use — for example, klp-2a should select a
>>> new set like set 3. The core design idea is to set replace_set
>>> dynamically. To determine which sets are already occupied, a
>>> user-space script can inspect /sys/kernel/livepatch/*/replace_set.
>>
>> How would Petr's 3rd way handle such dynamic replace_set enumeration?
>> Using the extended example above, without considering user patches, a
>> vendor could hardcode the replace_sets values at build time as shown.
>>
>> However, if a user patch has already occupied say, replace_set 3, then
>> klp-2b would need to skip over 3 and set replace_sets=4.  But then when
>> the next cumulative patch, klp-3a, loads, how does it know that it
>> should replace_sets=1,2,4 and leave 3 alone?
> 
>   Wed: klp-1a: cumulative    (replace_sets={1})
>   Thu: klp-1b: hotfix        (replace_sets={2})     <- coexists with klp-1a
>   Fri: klp-1c: hotfix v2     (replace_sets={2})     <- replaces klp-1b
> (same set)
>   Mon: klp-2a: cumulative    (replace_sets={1,2})   <- replaces klp-1a
> AND wipes klp-1c
>   Mon: klp-user: cumulative (replace_sets={3})  <- coexists with klp-2a
>   Tue: klp-2b: hotfix        (replace_sets={4})    <- choose an unused id
>   Wed: klp-3a: cumulative
> 
> When loading klp-3a, the user can inspect the currently active set IDs
> by checking /sys/kernel/livepatch/klp-2a/replace_set and
> /sys/kernel/livepatch/klp-2b/replace_set, then dynamically configure
> replace_sets to {1, 2, 4} accordingly.
> 

Ok, so the kernel only provides set ID information and userspace gets to
manage how it interacts (or not) with that.

A livepatch loading script could know to look for
/sys/kernel/livepatch/distro-*/replace_set to figure out it's previous
dynamically set IDs.  Local livepatches the same.  This would even allow
for groups of sets (vendor, customer1, customer2, etc.) if someone
wanted to complicate matters.

> However,  I don't have a strong opinion on this. If you both prefer
> the positional mode, I'm happy to implement it that way.
> 
We'll see what the others think.  To catch up with the thread, I'm
trying to run through these thought experiments to see how they play
out. :)

-- 
Joe