live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Shuah Khan <skhan@linuxfoundation.org>
Cc: Joe Lawrence <joe.lawrence@redhat.com>,
	Miroslav Benes <mbenes@suse.cz>,
	Marcos Paulo de Souza <mpdesouza@suse.com>,
	live-patching@vger.kernel.org, linux-kselftest@vger.kernel.org,
	shuah@kernel.org, jpoimboe@redhat.com
Subject: Re: [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch
Date: Fri, 2 Dec 2022 10:25:25 +0100	[thread overview]
Message-ID: <Y4nEhb7yPK5l54IX@alley> (raw)
In-Reply-To: <c5a6cb8a-7b99-249e-5ba4-732fc0ed2e30@linuxfoundation.org>

On Thu 2022-12-01 16:58:38, Shuah Khan wrote:
> On 11/30/22 15:22, Joe Lawrence wrote:
> > On 7/15/22 10:45 AM, Petr Mladek wrote:
> > > On Fri 2022-07-01 16:13:50, Shuah Khan wrote:
> > > > On 7/1/22 1:48 AM, Miroslav Benes wrote:
> > > > > On Thu, 30 Jun 2022, Shuah Khan wrote:
> > > > > > 
> > > > > > Sorry Nack on this. Let's not add modules under selftests. Any usage of
> > > > > > module_init()
> > > > > > doesn't belong under selftests.
> > > > 
> > > > Yes I did and after reviewing and thinking about it some more, I decided this
> > > > is the right direction go down on.
> > > 
> > > Do you have some particular reason why building modules in selftests
> > > directory might cause problems, please?
> > > 
> 
> My reasons are that with this change module_init() propagates out of
> strictly kernel space and now is in selftests which are user-space.
> Any changes to this interface will be tied to user-space change.

I am sorry but I do not understand the meaning here. module_init() is
called when module is loaded. It is not called in userspace.

Maybe, you mean that modules under lib/ are clearly in-tree
modules. If we move then under tools/ then they will be build
like out-of-tree modules. Except that they will be maintained in-tree
so that it will be easy to keep them in sync.

And I am sure that they will be actively maintained. The fixes are
there to make sure that livepatching still works as expected.
They must pass when any change is done in the livepatch subsystem.
And they must pass when any kernel is released.

The only concern might be how build failure is handled. IMHO, we
need to handle it the same way and test failure.


> In general, newer tests offer the best coverage, hence the recommendation
> to run newer tests on older kernels assuming that the tests are built
> on a newer kernel and backwards should run in a backwards compatible
> way on older kernels.

This works for the userspace interface that should always be backward
compatible. But it does not work for kABI.


> Do you have a requirement that livepatch test has to be revision
> matched with the kernel? Even if that is the case, there is no real
> reason to move modules under selftests other than keeping them in
> one location.

Yes, kABI is not backward compatible. But building the tests
modules out-of-tree way would allow to build test modules with
different kABI from the same sources.

IMHO, this is common for any selttests using kernel modules.
I am sure that neither test_printf nor test_scanf modules
could be loaded in older kernels. Even though it might
be useful to run improved tests for stable-like kernels.

Best Regards,
Petr

  parent reply	other threads:[~2022-12-02  9:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30 14:12 [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch Marcos Paulo de Souza
2022-06-30 14:12 ` [PATCH v2 1/2] " Marcos Paulo de Souza
2022-06-30 14:12 ` [PATCH v2 2/2] selftests: livepatch: Test livepatching a heavily called syscall Marcos Paulo de Souza
2022-07-12 14:56   ` Joe Lawrence
2022-07-29 13:19     ` Petr Mladek
2022-11-23 13:35     ` Marcos Paulo de Souza
2022-11-24  3:39       ` Marcos Paulo de Souza
2022-11-24 13:05     ` Marcos Paulo de Souza
2022-11-30 22:19       ` Joe Lawrence
2022-06-30 14:36 ` [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch Shuah Khan
2022-07-01  7:48   ` Miroslav Benes
2022-07-01 22:13     ` Shuah Khan
2022-07-15 14:45       ` Petr Mladek
2022-11-30 22:22         ` Joe Lawrence
2022-12-01 23:58           ` Shuah Khan
2022-12-02  7:33             ` Miroslav Benes
2022-12-02 20:17               ` Shuah Khan
2022-12-02  9:25             ` Petr Mladek [this message]
2022-12-02 20:03               ` Shuah Khan
2022-12-02 21:05                 ` Joe Lawrence
2022-12-05 17:30                   ` Marcos Paulo de Souza
2022-12-05 17:40                 ` 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=Y4nEhb7yPK5l54IX@alley \
    --to=pmladek@suse.com \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mpdesouza@suse.com \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.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;
as well as URLs for NNTP newsgroup(s).