On Fri, 1 Mar 2024 at 01:04, Mickaël Salaün wrote:
>
> Hi,
>
Thanks very much. I think there's a lot going on in this series, and
it'd probably be easier to address if it were broken up a bit more.
To take things one at a time:
> This patch series moves KUnit test execution at the very end of k
On Fri, 1 Mar 2024 at 01:04, Mickaël Salaün wrote:
>
> Run all the KUnit tests just before the first userspace code is
> launched. This makes it it possible to write new tests that check the
> kernel in its final state i.e., with all async __init code called,
> memory and RCU properly set up, an
Hi Mickaël,
kernel test robot noticed the following build warnings:
[auto build test WARNING on d206a76d7d2726f3b096037f2079ce0bd3ba329b]
url:
https://github.com/intel-lab-lkp/linux/commits/Micka-l-Sala-n/kunit-Run-tests-when-the-kernel-is-fully-setup/20240301-011020
base: d206a76d7d2726f3
Fix KUNIT_SUCCESS() calls to pass a test argument.
This is a no-op for now because this macro does nothing, but it will be
required for the next commit.
Cc: Brendan Higgins
Cc: David Gow
Cc: Rae Moar
Cc: Shuah Khan
Signed-off-by: Mickaël Salaün
---
lib/kunit_iov_iter.c | 18 +---
Previously, if a thread creation failed (e.g. -ENOMEM), the function was
called (kunit_catch_run_case or kunit_catch_run_case_cleanup) without
marking the test as failed. Instead, fill try_result with the error
code returned by kthread_run(), which will mark the test as failed and
print "internal
The exit code is always checked, so let's properly handle the -ETIMEDOUT
error code.
Cc: Brendan Higgins
Cc: David Gow
Cc: Rae Moar
Cc: Shuah Khan
Signed-off-by: Mickaël Salaün
---
lib/kunit/try-catch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/kunit/try-catch
Hi,
This patch series moves KUnit test execution at the very end of kernel
initialization, just before launching the init process. This opens the
way to test any kernel code in its normal state (i.e. fully
initialized).
This patch series also teaches KUnit to handle kthread faults as errors,
and
This helps identify the location of test faults.
Cc: Brendan Higgins
Cc: David Gow
Cc: Rae Moar
Cc: Shuah Khan
Signed-off-by: Mickaël Salaün
---
include/kunit/test.h | 24 +---
lib/kunit/try-catch.c | 10 +++---
2 files changed, 28 insertions(+), 6 deletions(-)
diff
Run all the KUnit tests just before the first userspace code is
launched. This makes it it possible to write new tests that check the
kernel in its final state i.e., with all async __init code called,
memory and RCU properly set up, and sysctl boot arguments evaluated.
The initial motivation is t
Previously, when a kernel test thread crashed (e.g. NULL pointer
dereference, general protection fault), the KUnit test hanged for 30
seconds and exited with a timeout error.
Fix this issue by waiting on task_struct->vfork_done instead of the
custom kunit_try_catch.try_completion, and track the ex
There is a race condition when a kthread finishes after the deadline and
before the call to kthread_stop(), which may lead to use after free.
Cc: Brendan Higgins
Cc: David Gow
Cc: Rae Moar
Cc: Shuah Khan
Signed-off-by: Mickaël Salaün
---
lib/kunit/try-catch.c | 9 ++---
1 file changed, 6
The first test checks NULL pointer dereference and make sure it would
result as a failed test.
The second and third tests check that read-only data is indeed read-only
and trying to modify it would result as a failed test.
This kunit_x86_fault test suite is marked as skipped when run on a
non-x86
On Thu, 29 Feb 2024 10:41:11 +0100, Johannes Berg
wrote:
> On Thu, 2024-02-29 at 04:34 -0500, Michael S. Tsirkin wrote:
> >
> > So the patchset is big, I guess it will take a couple of cycles to
> > merge gradually.
>
> Could also do patches 7, 8, and maybe 9 separately first (which seem
> reason
On Thu, 2024-02-29 at 04:34 -0500, Michael S. Tsirkin wrote:
>
> So the patchset is big, I guess it will take a couple of cycles to
> merge gradually.
Could also do patches 7, 8, and maybe 9 separately first (which seem
reasonable even on their own) and get rid of CC'ing so many people and
lists
On Thu, 29 Feb 2024 04:34:20 -0500, "Michael S. Tsirkin"
wrote:
> On Thu, Feb 29, 2024 at 05:02:37PM +0800, Xuan Zhuo wrote:
> > On Thu, 29 Feb 2024 03:21:14 -0500, "Michael S. Tsirkin"
> > wrote:
> > > On Thu, Feb 29, 2024 at 03:20:25PM +0800, Xuan Zhuo wrote:
> > > > As discussed:
> > > > htt
On Thu, Feb 29, 2024 at 05:02:37PM +0800, Xuan Zhuo wrote:
> On Thu, 29 Feb 2024 03:21:14 -0500, "Michael S. Tsirkin"
> wrote:
> > On Thu, Feb 29, 2024 at 03:20:25PM +0800, Xuan Zhuo wrote:
> > > As discussed:
> > > http://lore.kernel.org/all/cacgkmevq0no8qgc46u4mgsmtud44fd_cflcpavmj3rhyqrz...@ma
On Thu, 29 Feb 2024 03:21:14 -0500, "Michael S. Tsirkin"
wrote:
> On Thu, Feb 29, 2024 at 03:20:25PM +0800, Xuan Zhuo wrote:
> > As discussed:
> > http://lore.kernel.org/all/cacgkmevq0no8qgc46u4mgsmtud44fd_cflcpavmj3rhyqrz...@mail.gmail.com
> >
> > If the virtio is premapped mode, the driver shou
On Thu, Feb 29, 2024 at 03:20:25PM +0800, Xuan Zhuo wrote:
> As discussed:
> http://lore.kernel.org/all/cacgkmevq0no8qgc46u4mgsmtud44fd_cflcpavmj3rhyqrz...@mail.gmail.com
>
> If the virtio is premapped mode, the driver should manage the dma info by
> self.
> So the virtio core should not store th
18 matches
Mail list logo
