Thread (46 messages) flat view 46 messages, 5 authors, 1d ago

Re: Replace rules: was: Re: [PATCH v7 for-next 3/8] livepatch: Implement replace set for scoped atomic replace

From: Yafang Shao <hidden>
Date: 2026-09-06 08:34:46

On Fri, Sep 4, 2026 at 5:18 AM Song Liu [off-list ref] wrote:
On Thu, Sep 3, 2026 at 2:27 AM Petr Mladek [off-list ref] wrote:
[...]
quoted
quoted
quoted
Reasoning: The livepatch B replaces everything because it wants
        to be the only installed livepatch. It sounds weird
        to "break" it by installing A in parallel later again.
So, let's just not treat '0' as a special case?
I am not sure.

I personally think that '0' should not be special. A better solution
for a forced cleanup is the "replace_all" module option.
If we want '0' to be special, let's make it "not replace anything".
Then folks who prefer to have all the live patch loaded at the
same time have an easy solution.
Perhaps we should set aside the special handling of '0' for now. We
can always add it later if real use cases emerge.
quoted
The module option would need to be implemented in the livepatch code.
But it will need some support in the livepatch core as well, either
a flag in struct klp_patch or parameter in klp_enable_patch().
IMHO, the flag in struct klp_patch might be more practical.
What is the use case of replace_all?
With provides/obsoletes, the default behavior is 'replace all' if the
user doesn't set any IDs, because there can only be one livepatch
enabled. However, if the user explicitly sets provides and obsoletes
IDs, they are expected to understand how this feature works.
Personally, I lean towards not adding this replace_all flag.

-- 
Regards
Yafang
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help