[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZqEXC7NVStjPA9os@pathway.suse.cz>
Date: Wed, 24 Jul 2024 17:00:27 +0200
From: Petr Mladek <pmladek@...e.com>
To: zhang warden <zhangwarden@...il.com>
Cc: Miroslav Benes <mbenes@...e.cz>, Josh Poimboeuf <jpoimboe@...nel.org>,
Jiri Kosina <jikos@...nel.org>,
Joe Lawrence <joe.lawrence@...hat.com>,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: Add using attribute to klp_func for using
func show
On Sat 2024-07-20 13:56:56, zhang warden wrote:
>
> > is this always correct though? See the logic in klp_ftrace_handler(). If
> > there is a transition running, it is a little bit more complicated.
> >
> > Miroslav
>
> Hi! Miroslav.
>
> In reality, we often encounter such situation that serval patch in one system, some patch make changes to one same function A. This make us confused that we don't know which version of function A is now using.
>
> In my view, this "using" state show the function version that is now enabling. Even if there is a transition running, the end state of one task will finally use patchN's version.
>
> If we see the attribute "using" is 1, it mean that livepatch will use this function to work but seem to be not all task running this version because the "transition" flag of this patch is "1". We can be told from "transition" that if all threads have completed synchronization.
>
> So, the main function of this attribute is to enable user space find out which version of the patched function is running now (or will use after transition completed)in the system.
The value is useless when the transition is in progress.
You simply do not know which variant is used in this case.
Which brings the question how exactly you use the value.
Could you please provide an example of decision which you make based
on the value?
If we agree that it makes sense then we should make it 3-state
where the meaning of values would be:
-1: unknown (transition in progress)
0: unused
1: used
Best Regards,
Petr
Powered by blists - more mailing lists