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: 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, joe.lawrence@redhat.com
Subject: Re: [PATCH v2 0/2] livepatch: Move tests from lib/livepatch to selftests/livepatch
Date: Fri, 15 Jul 2022 16:45:26 +0200	[thread overview]
Message-ID: <20220715144526.GF2737@pathway.suse.cz> (raw)
In-Reply-To: <8ff95ef5-db76-171d-4c4c-a84d9981290d@linuxfoundation.org>

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?

IMHO, the reason that the test modules are in lib is because the
modules were there before selftests. Developers historically loaded them
manually or they were built-in. Selftest were added later and are just
another way how the module can be loaded. This is the case,
for example, for lib/test_printf.c.

Otherwise, I do not see any big difference between building binaries
and modules under tools/tests/selftests. As I said, in the older
thread, IMHO, it makes more sense to have the selftest sources
self-contained.


There actually seems to be a principal problem in the following use
case:

--- cut Documentation/dev-tools/kselftest.rst ---
Kselftest from mainline can be run on older stable kernels. Running tests
from mainline offers the best coverage. Several test rings run mainline
kselftest suite on stable releases. The reason is that when a new test
gets added to test existing code to regression test a bug, we should be
able to run that test on an older kernel. Hence, it is important to keep
code that can still test an older kernel and make sure it skips the test
gracefully on newer releases.
--- cut Documentation/dev-tools/kselftest.rst ---

together with

--- cut Documentation/dev-tools/kselftest.rst ---
 * First use the headers inside the kernel source and/or git repo, and then the
   system headers.  Headers for the kernel release as opposed to headers
   installed by the distro on the system should be the primary focus to be able
   to find regressions.
--- cut Documentation/dev-tools/kselftest.rst ---

It means that selftests should support running binaries built against
newer kernel sources on system running older kernel. But this might
be pretty hard to achieve and maintain.

The normal kernel rules are exactly the opposite. Old binaries must
be able to run on newer kernels. The old binaries were built against
older headers.

IMHO, the testing of stable kernels makes perfect sense. And if we
want to support it seriously than we need to allow building new
selftests against headers from the old to-be-tested kernel. And
it will be possible only when the selftests sources are as much
selfcontained as possible.

Does this makes any sense, please?

Best Regards,
Petr

  reply	other threads:[~2022-07-15 14:45 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 [this message]
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
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=20220715144526.GF2737@pathway.suse.cz \
    --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).