-
Mark Brown, Veronika Kabatova12/09/2022, 15:00
Currently we often have a fairly big disconnect between generic testing and quality efforts and the work of developers and maintainers. There is a lot of testing that is done by people working on the kernel that is not covered by what the general testing efforts do, and conversely it is often hard for developers and maintainers to access broader community resources when extra testing is...
Go to contribution page -
David Vernet (Meta)12/09/2022, 15:30
There are a number of tools available for writing tests in the kernel. One
of them is kselftest, which is a system for writing end-to-end tests. Another
is KUnit, which runs unit tests directly in the kernel.These testing tools are very useful, but they lack the ability for maintainers
Go to contribution page
to configure how the tests should be run. For example, patches submitted to the
RCU tree and branch... -
Aleksandr Nogikh (Google)12/09/2022, 15:50
Since 2017, [syzbot][1] (powered by [syzkaller][2] - a coverage-guided kernel fuzzer) has already reported [thousands][3] of bugs to the Linux kernel mailing lists and [thousands][4] have already been fixed.
However, as our statistics [show][5], a lot of reported issues get fixed only after a long delay or don't get fixed at all. That means we could still do much better in addressing the...
Go to contribution page -
Dmitry Vyukov (Google)12/09/2022, 16:10
Fuzzing (randomized testing) become an important part of the kernel quality assurance. [syzkaller][1]/[syzbot][2] report a [hundred of bugs][3] each month. However, the fuzzer coverage of the kernel code is far from being complete and some subsystems are easier to fuzz/reach, while others are harder/impossible to fuzz/reach.
Go to contribution page
In this talk Dmitry will talk about patterns and anti-patterns... -
philip li12/09/2022, 17:00
Linux kernel community has formed a virtual QA team and testing process gradually, from developing unit testing, to testing service (various CI that covers build, fuzzing and runtime), to result consolidation (KCIDB) to bug scrub (regzbot), which largely formalize the testing effort in community wide. 0-Day CI is glad to be part of this progress.
In this topic, we will talk about the status...
Go to contribution page -
Brendan Higgins (Google LLC), David Gow (Google)12/09/2022, 17:20
Despite everyone's efforts, there's still more kernel to test. One problem area that keeps popping up is the need to replace functions with 'fake' or 'mock' equivalents in order to test hardware or less-self-contained subsystems. We will discuss two methods of replacing functions: one based on ftrace, and another based on "static stubbing" using a function prologue.
We will also provide a...
Go to contribution page -
Isabella Basso, Magali Lemes, Maíra Canal, Tales da Aparecida12/09/2022, 17:40
Unit testing is a great way to ensure code reliability, leading to organic improvements, as it's often possible to integrate it with developers' workflows. It is also of great help when refactoring, which should be a primordial task in large code bases. When it comes to the Linux kernel, the KUnit framework looks very promising, as it works natively from inside the kernel, and provides an...
Go to contribution page -
Jan Lübbe (Pengutronix)12/09/2022, 18:00
While most current KernelCI labs use Lava to deploy and test the Kernels
on real hardware, other approaches are supported by KernelCI's design.To allow using boards connected to an existing labgrid installation,
Jan build a small adapter from KernelCI's API to labgrid's hardware
control Python API.As labgrid has a way to support board-specific deployment steps,
Go to contribution page
this should also...
Choose timezone
Your profile timezone: