From: Petr Mladek <pmladek@suse.com>
To: Marcos Paulo de Souza <mpdesouza@suse.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
Shuah Khan <shuah@kernel.org>,
live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] selftests: livepatch: Test atomic replace against multiple modules
Date: Mon, 3 Jun 2024 14:52:45 +0200 [thread overview]
Message-ID: <Zl28ne_laBawq-KP@pathway.suse.cz> (raw)
In-Reply-To: <92d683bd138a76e6c7100f4984be202dd06c9424.camel@suse.com>
On Fri 2024-05-31 18:06:48, Marcos Paulo de Souza wrote:
> On Fri, 2024-05-31 at 15:44 -0400, Joe Lawrence wrote:
> > On Sat, May 25, 2024 at 11:34:08AM -0300, Marcos Paulo de Souza
> > wrote:
> > > Adapt the current test-livepatch.sh script to account the number of
> > > applied livepatches and ensure that an atomic replace livepatch
> > > disables
> > > all previously applied livepatches.
> > >
> > > Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
> > > ---
> > > Changes since v1:
> > > * Added checks in the existing test-livepatch.sh instead of
> > > creating a
> > > new test file. (Joe)
> > > * Fixed issues reported by ShellCheck (Joe)
> > > ---
> > > .../testing/selftests/livepatch/test-livepatch.sh | 46
> > > ++++++++++++++++++++--
> > > 1 file changed, 42 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/tools/testing/selftests/livepatch/test-livepatch.sh
> > > b/tools/testing/selftests/livepatch/test-livepatch.sh
> > > index e3455a6b1158..d85405d18e54 100755
> > > --- a/tools/testing/selftests/livepatch/test-livepatch.sh
> > > +++ b/tools/testing/selftests/livepatch/test-livepatch.sh
> > > @@ -107,9 +107,12 @@ livepatch: '$MOD_LIVEPATCH': unpatching
> > > complete
> > >
> > > # - load a livepatch that modifies the output from /proc/cmdline
> > > and
> > > # verify correct behavior
> > > -# - load an atomic replace livepatch and verify that only the
> > > second is active
> > > -# - remove the first livepatch and verify that the atomic replace
> > > livepatch
> > > -# is still active
> > > +# - load two addtional livepatches and check the number of
> > > livepatch modules
> > > +# applied
> > > +# - load an atomic replace livepatch and check that the other
> > > three modules were
> > > +# disabled
> > > +# - remove all livepatches besides the atomic replace one and
> > > verify that the
> > > +# atomic replace livepatch is still active
> > > # - remove the atomic replace livepatch and verify that none are
> > > active
> > >
> > > start_test "atomic replace livepatch"
> > > @@ -119,12 +122,31 @@ load_lp $MOD_LIVEPATCH
> > > grep 'live patched' /proc/cmdline > /dev/kmsg
> > > grep 'live patched' /proc/meminfo > /dev/kmsg
> > >
> > > +for mod in test_klp_syscall test_klp_callbacks_demo; do
> >
> > Slightly nitpicky here, but the tests were originally written with
> > the
> > livepatch module names via variables like $MOD_LIVEPATCH. Would
> > using
> > $MOD_LIVEPATCH{1,2,3} help indicate that their specifics aren't
> > really
> > interesting, that we just need 3 of them?
>
> Makes sense. I thought about it when I was changing the code, but I
> didn't want to change it too much, so it was the result. But that makes
> sense to have the modules better named.
I like this.
> > > + load_lp $mod
> > > +done
> > > +
> > > +mods=(/sys/kernel/livepatch/*)
> > > +nmods=${#mods[@]}
> > > +if [ "$nmods" -ne 3 ]; then
> > > + die "Expecting three modules listed, found $nmods"
> > > +fi
> > > +
> >
> > I was going to suggest that we might protect against a situation
> > where
> > other livepatch modules were active, that a simple count wouldn't be
> > sufficient. But then I thought about this test, atomic replace!
> > Anything previously loaded is going to be pushed aside anyway.
> >
> > So maybe (in another patch or set) it would be worth enhancing
> > functions.sh :: start_test() do a quick sanity check to see that the
> > initial conditions are safe? That might also prevent some collateral
> > damage when test A fails and leaves the world a strange place for
> > tests
> > B, C, etc.
>
> We have been discussing about start/end functions that would check for
> leftover modules... maybe should be a good think to implement soon as
> we land more tests.
Makes sense :-)
> > > load_lp $MOD_REPLACE replace=1
> > >
> > > grep 'live patched' /proc/cmdline > /dev/kmsg
> > > grep 'live patched' /proc/meminfo > /dev/kmsg
> > >
> > > -unload_lp $MOD_LIVEPATCH
> > > +mods=(/sys/kernel/livepatch/*)
> > > +nmods=${#mods[@]}
> > > +if [ "$nmods" -ne 1 ]; then
> > > + die "Expecting only one moduled listed, found $nmods"
> > > +fi
> > > +
> > > +# These modules were disabled by the atomic replace
> > > +for mod in test_klp_callbacks_demo test_klp_syscall
> > > $MOD_LIVEPATCH; do
> > > + unload_lp "$mod"
> > > +done
> > >
> > > grep 'live patched' /proc/cmdline > /dev/kmsg
> > > grep 'live patched' /proc/meminfo > /dev/kmsg
> > > @@ -142,6 +164,20 @@ livepatch: '$MOD_LIVEPATCH': starting patching
> > > transition
> > > livepatch: '$MOD_LIVEPATCH': completing patching transition
> > > livepatch: '$MOD_LIVEPATCH': patching complete
> > > $MOD_LIVEPATCH: this has been live patched
> > > +% insmod test_modules/test_klp_syscall.ko
> >
> > Similar minor nit here, too. If we think copy/pasting all the
> > $MOD_FOO
> > is annoying, I am fine with leaving this as is. I don't have a
> > strong
> > opinion other than following some convention.
> >
> > With that, I'm happy to ack as-is or with variable names.
>
> Thanks Joe! I think that is Petr's call, either way I can rework this
> patch, or send additional ones to adjust the tests.
I would prefer if you did respin this patch. The use of
$MOD_LIVEPATCH{1,2,3} would make even the patch easier to follow.
Best Regards,
Petr
next prev parent reply other threads:[~2024-06-03 12:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-25 14:34 [PATCH v2] selftests: livepatch: Test atomic replace against multiple modules Marcos Paulo de Souza
2024-05-28 15:01 ` Petr Mladek
2024-05-29 14:05 ` Miroslav Benes
2024-05-31 19:44 ` Joe Lawrence
2024-05-31 21:06 ` Marcos Paulo de Souza
2024-06-03 12:52 ` Petr Mladek [this message]
2024-06-03 17:29 ` Marcos Paulo de Souza
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=Zl28ne_laBawq-KP@pathway.suse.cz \
--to=pmladek@suse.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=mpdesouza@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.