[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPhsuW7bjyLvfQ-ysKE+S8x26Zv5b7jbJoyW8UiBaUfaRncKfg@mail.gmail.com>
Date: Tue, 4 Jun 2024 22:04:42 -0700
From: Song Liu <song@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Miroslav Benes <mbenes@...e.cz>, zhang warden <zhangwarden@...il.com>,
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: introduce klp_func called interface
On Tue, May 21, 2024 at 1:04 AM Petr Mladek <pmladek@...e.com> wrote:
[...]
> >
> > 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.
>
> Another motivation to use ftrace for testing is that it does not
> affect the performance in production.
>
> We should keep klp_ftrace_handler() as fast as possible so that we
> could livepatch also performance sensitive functions.
At LPC last year, we discussed about adding a counter to each
klp_func, like:
struct klp_func {
...
u64 __percpu counter;
...
};
With some static_key (+ sysctl), this should give us a way to estimate
the overhead of livepatch. If we have the counter, this patch is not
needed any more. Does this (adding the counter) sound like
something we still want to pursue?
Thanks,
Song
Powered by blists - more mailing lists