From: Marcos Paulo de Souza <mpdesouza@suse.com>
To: Filipe Xavier <felipeaggger@gmail.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
Shuah Khan <shuah@kernel.org>
Cc: live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org,
Felipe Xavier <felipe_life@live.com>
Subject: Re: [PATCH v2] selftests: livepatch: test if ftrace can trace a livepatched function
Date: Tue, 14 Jan 2025 14:18:02 -0300 [thread overview]
Message-ID: <12c6681e2d13994c2efd5d25372293b9f53a9f8a.camel@suse.com> (raw)
In-Reply-To: <20250111-ftrace-selftest-livepatch-v2-1-9f4ff90f251a@gmail.com>
On Sat, 2025-01-11 at 15:42 -0300, Filipe Xavier wrote:
> This new test makes sure that ftrace can trace a
> function that was introduced by a livepatch.
>
> Signed-off-by: Filipe Xavier <felipeaggger@gmail.com>
Thanks for the new test Filipe!
I have some nits below, but these don't need to be addressed for the
test to be merged. Either way,
Reviewed-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Tested-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> ---
> Changes in v2:
> - functions.sh: added reset tracing on push and pop_config.
> - test-ftrace.sh: enabled tracing_on before test init.
> - nitpick: added double quotations on filenames and fixed some
> wording.
> - Link to v1:
> https://lore.kernel.org/r/20250102-ftrace-selftest-livepatch-v1-1-84880baefc1b@gmail.com
> ---
> tools/testing/selftests/livepatch/functions.sh | 14 ++++++++++
> tools/testing/selftests/livepatch/test-ftrace.sh | 33
> ++++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/tools/testing/selftests/livepatch/functions.sh
> b/tools/testing/selftests/livepatch/functions.sh
> index
> e5d06fb402335d85959bafe099087effc6ddce12..e6c13514002dae5f8d7461f90b8
> 241ab43024ea4 100644
> --- a/tools/testing/selftests/livepatch/functions.sh
> +++ b/tools/testing/selftests/livepatch/functions.sh
> @@ -62,6 +62,9 @@ function push_config() {
> awk -F'[: ]' '{print "file " $1 " line " $2
> " " $4}')
> FTRACE_ENABLED=$(sysctl --values kernel.ftrace_enabled)
> KPROBE_ENABLED=$(cat "$SYSFS_KPROBES_DIR/enabled")
> + TRACING_ON=$(cat "$SYSFS_DEBUG_DIR/tracing/tracing_on")
> + CURRENT_TRACER=$(cat
> "$SYSFS_DEBUG_DIR/tracing/current_tracer")
> + FTRACE_FILTER=$(cat
> "$SYSFS_DEBUG_DIR/tracing/set_ftrace_filter")
> }
>
> function pop_config() {
> @@ -74,6 +77,17 @@ function pop_config() {
> if [[ -n "$KPROBE_ENABLED" ]]; then
> echo "$KPROBE_ENABLED" >
> "$SYSFS_KPROBES_DIR/enabled"
> fi
> + if [[ -n "$TRACING_ON" ]]; then
> + echo "$TRACING_ON" >
> "$SYSFS_DEBUG_DIR/tracing/tracing_on"
> + fi
> + if [[ -n "$CURRENT_TRACER" ]]; then
> + echo "$CURRENT_TRACER" >
> "$SYSFS_DEBUG_DIR/tracing/current_tracer"
> + fi
> + if [[ "$FTRACE_FILTER" == *"#"* ]]; then
> + echo > "$SYSFS_DEBUG_DIR/tracing/set_ftrace_filter"
> + elif [[ -n "$FTRACE_FILTER" ]]; then
> + echo "$FTRACE_FILTER" >
> "$SYSFS_DEBUG_DIR/tracing/set_ftrace_filter"
> + fi
> }
I believe that this could be a separate patch, since this is new
functionality that's being added to functions.sh, and not exactly
related to the new test.
>
> function set_dynamic_debug() {
> diff --git a/tools/testing/selftests/livepatch/test-ftrace.sh
> b/tools/testing/selftests/livepatch/test-ftrace.sh
> index
> fe14f248913acbec46fb6c0fec38a2fc84209d39..66af5d726c52e48e5177804e182
> b4ff31784d5ac 100755
> --- a/tools/testing/selftests/livepatch/test-ftrace.sh
> +++ b/tools/testing/selftests/livepatch/test-ftrace.sh
> @@ -61,4 +61,37 @@ livepatch: '$MOD_LIVEPATCH': unpatching complete
> % rmmod $MOD_LIVEPATCH"
>
>
> +# - verify livepatch can load
> +# - check if traces have a patched function
> +# - unload livepatch and reset trace
> +
> +start_test "trace livepatched function and check that the live patch
> remains in effect"
> +
> +TRACE_FILE="$SYSFS_DEBUG_DIR/tracing/trace"
> +FUNCTION_NAME="livepatch_cmdline_proc_show"
> +
> +load_lp $MOD_LIVEPATCH
> +
> +echo 1 > "$SYSFS_DEBUG_DIR/tracing/tracing_on"
> +echo $FUNCTION_NAME > "$SYSFS_DEBUG_DIR/tracing/set_ftrace_filter"
> +echo "function" > "$SYSFS_DEBUG_DIR/tracing/current_tracer"
> +echo "" > "$TRACE_FILE"
> +
> +if [[ "$(cat /proc/cmdline)" != "$MOD_LIVEPATCH: this has been live
> patched" ]] ; then
> + echo -e "FAIL\n\n"
> + die "livepatch kselftest(s) failed"
> +fi
> +
> +grep -q $FUNCTION_NAME "$TRACE_FILE"
> +FOUND=$?
> +
> +disable_lp $MOD_LIVEPATCH
> +unload_lp $MOD_LIVEPATCH
> +
> +if [ "$FOUND" -eq 1 ]; then
> + echo -e "FAIL\n\n"
> + die "livepatch kselftest(s) failed"
> +fi
> +
> +
> exit 0
The test works, and that's very cool. But when running locally, I find
the if we miss check_result call it doesn't add a newline after the
"ok":
...
# timeout set to 0
# selftests: livepatch: test-ftrace.sh
# TEST: livepatch interaction with ftrace_enabled sysctl ... ok
# TEST: trace livepatched function and check that the live patch
remains in effect ... ok 5 selftests: livepatch: test-ftrace.sh
# timeout set to 0
# selftests: livepatch: test-sysfs.sh
...
If the check_result below is added the output if sane again:
...
# selftests: livepatch: test-ftrace.sh
# TEST: livepatch interaction with ftrace_enabled sysctl ... ok
# TEST: trace livepatched function and check that the live patch
remains in effect ... ok
ok 5 selftests: livepatch: test-ftrace.sh
...
I checked and this would be the only one test without using
check_result, so maybe we should add this either way? I'm not sure what
you guys think about it.
diff --git a/tools/testing/selftests/livepatch/test-ftrace.sh
b/tools/testing/selftests/livepatch/test-ftrace.sh
index 66af5d726c52..135c0fb17a98 100755
--- a/tools/testing/selftests/livepatch/test-ftrace.sh
+++ b/tools/testing/selftests/livepatch/test-ftrace.sh
@@ -93,5 +93,18 @@ if [ "$FOUND" -eq 1 ]; then
die "livepatch kselftest(s) failed"
fi
+check_result "% insmod test_modules/$MOD_LIVEPATCH.ko
+livepatch: enabling patch '$MOD_LIVEPATCH'
+livepatch: '$MOD_LIVEPATCH': initializing patching transition
+livepatch: '$MOD_LIVEPATCH': starting patching transition
+livepatch: '$MOD_LIVEPATCH': completing patching transition
+livepatch: '$MOD_LIVEPATCH': patching complete
+% echo 0 > $SYSFS_KLP_DIR/$MOD_LIVEPATCH/enabled
+livepatch: '$MOD_LIVEPATCH': initializing unpatching transition
+livepatch: '$MOD_LIVEPATCH': starting unpatching transition
+livepatch: '$MOD_LIVEPATCH': completing unpatching transition
+livepatch: '$MOD_LIVEPATCH': unpatching complete
+% rmmod $MOD_LIVEPATCH"
+
exit 0
>
> ---
> base-commit: fc033cf25e612e840e545f8d5ad2edd6ba613ed5
> change-id: 20250101-ftrace-selftest-livepatch-161fb77dbed8
>
> Best regards,
next prev parent reply other threads:[~2025-01-14 17:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-11 18:42 [PATCH v2] selftests: livepatch: test if ftrace can trace a livepatched function Filipe Xavier
2025-01-14 17:18 ` Marcos Paulo de Souza [this message]
2025-01-15 15:03 ` Joe Lawrence
2025-01-15 15:31 ` Petr Mladek
2025-03-06 22:12 ` Filipe Xavier
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=12c6681e2d13994c2efd5d25372293b9f53a9f8a.camel@suse.com \
--to=mpdesouza@suse.com \
--cc=felipe_life@live.com \
--cc=felipeaggger@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
--cc=shuah@kernel.org \
/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