On Tue, Jun 04, 2024 at 04:14:51PM +0800, zhang warden wrote:
>
>
> > On Jun 1, 2024, at 03:16, Joe Lawrence <joe.lawrence@xxxxxxxxxx> wrote:
> >
> > Adding these attributes to livepatch sysfs would be expedient and
> > probably easier for us to use, but imposes a recurring burden on us to
> > maintain and test (where is the documentation and kselftest for this new
> > interface?). Or, we could let the other tools handle all of that for
> > us.
> How this attribute imposes a recurring burden to maintain and test?
>
Perhaps "responsibility" is a better description. This would introduce
an attribute that someone's userspace utility is relying on. It should
at least have a kselftest to ensure a random patch in 2027 doesn't break
it.
> > Perhaps if someone already has an off-the-shelf script that is using
> > ftrace to monitor livepatched code, it could be donated to
> > Documentation/livepatch/? I can ask our QE folks if they have something
> > like this.
>
> My intention to introduce this attitude to sysfs is that user who what to see if this function is called can just need to show this function attribute in the livepatch sysfs interface.
>
> User who have no experience of using ftrace will have problems to get the calling state of the patched function. After all, ftrace is a professional kernel tracing tools.
>
> Adding this attribute will be more easier for us to show if this patched function is called. Actually, I have never try to use ftrace to trace a patched function. Is it OK of using ftrace for a livepatched function?
>
If you build with CONFIG_SAMPLE_LIVEPATCH=m, you can try it out (or with
one of your own livepatches):
# Convenience variable
$ SYSFS=/sys/kernel/debug/tracing
# Install the livepatch sample demo module
$ insmod samples/livepatch/livepatch-sample.ko
# Verify that ftrace can filter on our functions
$ grep cmdline_proc_show $SYSFS/available_filter_functions
cmdline_proc_show
livepatch_cmdline_proc_show [livepatch_sample]
# Turn off any existing tracing and filter functions
$ echo 0 > $SYSFS/tracing_on
$ echo > $SYSFS/set_ftrace_filter
# Set up the function tracer and add the kernel's cmdline_proc_show()
# and livepatch-sample's livepatch_cmdline_proc_show()
$ echo function > $SYSFS/current_tracer
$ echo cmdline_proc_show >> $SYSFS/set_ftrace_filter
$ echo livepatch_cmdline_proc_show >> $SYSFS/set_ftrace_filter
$ cat $SYSFS/set_ftrace_filter
cmdline_proc_show
livepatch_cmdline_proc_show [livepatch_sample]
# Turn on the ftracing and force execution of the original and
# livepatched functions
$ echo 1 > $SYSFS/tracing_on
$ cat /proc/cmdline
this has been live patched
# Checkout out the trace file results
$ cat $SYSFS/trace
# tracer: function
#
# entries-in-buffer/entries-written: 2/2 #P:8
#
# _-----=> irqs-off/BH-disabled
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / _-=> migrate-disable
# |||| / delay
# TASK-PID CPU# ||||| TIMESTAMP FUNCTION
# | | | ||||| | |
cat-254 [002] ...2. 363.043498: cmdline_proc_show <-seq_read_iter
cat-254 [002] ...1. 363.043501: livepatch_cmdline_proc_show <-seq_read_iter
The kernel docs provide a lot of explanation of the complete ftracing
interface. It's pretty power stuff, though you may also go the other
direction and look into using the trace-cmd front end to simplify all of
the sysfs manipulation. Julia Evans wrote a blog [1] a while back that
provides a some more examples.
[1] https://jvns.ca/blog/2017/03/19/getting-started-with-ftrace/
--
Joe
