Live Patching
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox