Re: [PATCH] livepatch: introduce klp_func called interface

[Miroslav Benes <mbenes@suse.cz>]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

Hi,

On Tue, 4 Jun 2024, Song Liu wrote:

> On Tue, May 21, 2024 at 1:04 AM Petr Mladek <pmladek@suse.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?

It would be better than this patch but given what was mentioned in the 
thread I wonder if it is possible to use ftrace even for this. See 
/sys/kernel/tracing/trace_stat/function*. It already gathers the number of 
hits.

Would it be sufficient for you? I guess it depends on what the intention 
is. If there is no time limit, klp_func.counter might be better to provide 
some kind of overall statistics (but I am not sure if it has any value) 
and to avoid having ftrace registered on a live patched function for 
infinite period of time. If the intention is to gather data for some 
limited period, trace_stat sounds like much better approach to me.

Regards
Miroslav