From: Petr Mladek <pmladek@suse.com>
To: zhang warden <zhangwarden@gmail.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 17:00:27 +0200 [thread overview]
Message-ID: <ZqEXC7NVStjPA9os@pathway.suse.cz> (raw)
In-Reply-To: <07DD1CA1-7E53-4E67-92DC-ECEC11424804@gmail.com>
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
next prev parent reply other threads:[~2024-07-24 15:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:28 [PATCH] livepatch: Add using attribute to klp_func for using func show zhangyongde.zyd
2024-07-19 12:09 ` Miroslav Benes
2024-07-20 5:56 ` zhang warden
2024-07-24 15:00 ` Petr Mladek [this message]
2024-07-24 15:20 ` zhang warden
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=ZqEXC7NVStjPA9os@pathway.suse.cz \
--to=pmladek@suse.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=zhangwarden@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.