From: Miroslav Benes <mbenes@suse.cz>
To: zhang warden <zhangwarden@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] livepatch: introduce klp_func called interface
Date: Tue, 21 May 2024 08:34:46 +0200 (CEST) [thread overview]
Message-ID: <alpine.LSU.2.21.2405210823590.4805@pobox.suse.cz> (raw)
In-Reply-To: <BBD2A553-6D44-4CD5-94DD-D8B2D5536F94@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]
Hello,
On Mon, 20 May 2024, zhang warden wrote:
>
>
> > On May 20, 2024, at 14:46, Miroslav Benes <mbenes@suse.cz> wrote:
> >
> > Hi,
> >
> > On Mon, 20 May 2024, Wardenjohn wrote:
> >
> >> Livepatch module usually used to modify kernel functions.
> >> If the patched function have bug, it may cause serious result
> >> such as kernel crash.
> >>
> >> This is a kobject attribute of klp_func. Sysfs interface named
> >> "called" is introduced to livepatch which will be set as true
> >> if the patched function is called.
> >>
> >> /sys/kernel/livepatch/<patch>/<object>/<function,sympos>/called
> >>
> >> This value "called" is quite necessary for kernel stability
> >> assurance for livepatching module of a running system.
> >> Testing process is important before a livepatch module apply to
> >> a production system. With this interface, testing process can
> >> easily find out which function is successfully called.
> >> Any testing process can make sure they have successfully cover
> >> all the patched function that changed with the help of this interface.
> >
> > Even easier is to use the existing tracing infrastructure in the kernel
> > (ftrace for example) to track the new function. You can obtain much more
> > information with that than the new attribute provides.
> >
> > Regards,
> > Miroslav
> Hi Miroslav
>
> First, in most cases, testing process is should be automated, which make
> using existing tracing infrastructure inconvenient.
could you elaborate, please? We use ftrace exactly for this purpose and
our testing process is also more or less automated.
> Second, livepatch is
> already use ftrace for functional replacement, I don’t think it is a
> good choice of using kernel tracing tool to trace a patched function.
Why?
> At last, this attribute can be thought of as a state of a livepatch
> function. It is a state, like the "patched" "transition" state of a
> klp_patch. Adding this state will not break the state consistency of
> livepatch.
Yes, but the information you get is limited compared to what is available
now. You would obtain the information that a patched function was called
but ftrace could also give you the context and more.
It would not hurt to add a new attribute per se but I am wondering about
the reason and its usage. Once we have it, the commit message should be
improved based on that.
Regards,
Miroslav
next prev parent reply other threads:[~2024-05-21 6:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-20 0:58 Wardenjohn
2024-05-20 6:46 ` Miroslav Benes
2024-05-20 7:10 ` zhang warden
2024-05-21 6:34 ` Miroslav Benes [this message]
2024-05-21 8:04 ` Petr Mladek
2024-05-24 8:09 ` zhang warden
2024-05-31 2:16 ` zhang warden
2024-05-31 7:21 ` Miroslav Benes
2024-05-31 13:19 ` zhang warden
2024-05-31 14:06 ` Miroslav Benes
2024-06-04 8:17 ` zhang warden
2024-06-05 5:04 ` Song Liu
2024-06-07 9:07 ` Miroslav Benes
2024-06-07 16:59 ` Song Liu
2024-06-11 2:23 ` zhang warden
2024-06-20 3:39 ` zhang warden
2024-06-20 9:31 ` Miroslav Benes
2024-05-31 19:16 ` Joe Lawrence
2024-06-04 8:14 ` zhang warden
2024-06-04 11:01 ` zhang warden
2024-06-04 14:37 ` Joe Lawrence
2024-06-05 2:38 ` zhang warden
2024-06-06 15:01 ` Joe Lawrence
2024-06-07 2:26 ` zhang warden
2024-05-20 8:00 ` Markus Elfring
2024-05-20 9:34 ` zhang warden
-- strict thread matches above, loose matches on Subject: below --
2024-05-19 7:43 Wardenjohn
2024-05-19 18:05 ` Markus Elfring
2024-05-19 23:42 ` zhang warden
2024-05-23 14:22 ` Dan Carpenter
2024-05-24 8:12 ` 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=alpine.LSU.2.21.2405210823590.4805@pobox.suse.cz \
--to=mbenes@suse.cz \
--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=pmladek@suse.com \
--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
all inboxes | Powered by JetHome®