From: zhang warden <zhangwarden@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] livepatch: Add using attribute to klp_func for using func show
Date: Wed, 24 Jul 2024 23:20:34 +0800 [thread overview]
Message-ID: <1A0E6D0A-4245-4F44-8667-CDD86A925347@gmail.com> (raw)
In-Reply-To: <ZqEXC7NVStjPA9os@pathway.suse.cz>
Hi Petr!
> The value is useless when the transition is in progress.
> You simply do not know which variant is used in this case.
>
Yes, I agree that if the patch is in transition, we can not know which version of this function is running by one task.
As my previous explanation, each patch have a state "transition" to show if this patch is under transition state. If this function "using" is 1, it shows that this function is going to become the version to be use, but not all the task use this newest version because some task is under transition (this is the "unknown" state from your opinion).
> 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?
>
Here I can give you an example.
We are going to fix a problem of io_uring.
Our team made a livepatch of io_sq_offload_create.
This livepatch module is deployed to some running servers.
Then, another team make some change to the same function and deployed it to the same cluster.
Finally, they found that there are some livepatch module modifying the same function io_sq_offload_create. But none of them can tell which version of io_sq_offload_create is now exactly running in the system.
We can only use crash to debug /proc/kcore to see if we can get more information from the kcore.
If livepatch can tell which version of the function is now running or going to run, it will be very useful.
> 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
>
Yeah, I agree with this state. I combine "transition" and "using" to tell the unknown state. It can be better if this state can be shown in using flag.
Thanks!
Wardenjohn
prev parent reply other threads:[~2024-07-24 15:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:28 zhangyongde.zyd
2024-07-19 12:09 ` Miroslav Benes
2024-07-20 5:56 ` zhang warden
2024-07-24 15:00 ` Petr Mladek
2024-07-24 15:20 ` zhang warden [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1A0E6D0A-4245-4F44-8667-CDD86A925347@gmail.com \
--to=zhangwarden@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®