On Tue, Mar 29, 2022 at 5:20 AM Marcelo Schmitt <marcelo.schmitt1@xxxxxxxxx> wrote: > > Complement the Kernel Testing Guide documentation page by adding a > section about static analysis tools. > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt1@xxxxxxxxx> > --- > Hey everyone, > > I think this patch can be a good addition to the documentation as > discussed in the thread for the testing guide documentation page: > Link: https://lore.kernel.org/linux-doc/CABVgOS=2iYtqTVdxwH=mcFpcSuLP4cpJ4s6PKP4Gc-SH6jidgQ@xxxxxxxxxxxxxx/ > > If you think it would be worth it, I can try making something more > elaborated. Maybe provide some guidance on when to use each tool. > I've been studying how Linux device drivers are tested. > Here's a post I wrote talking about some testing tools. > Link: https://marcelosc.gitlab.io/how-is-linux-tested/ > > Best regards, > Marcelo > Thanks a lot for adding to this, and for writing that blog post, which I think is an excellent overview itself. I'd definitely like to see more of it work its way into this document. (While we've largely stuck to tools which are in-tree thus far, I think we'd definitely benefit from discussion of, for example, the different CI systems.) One thing which isn't totally clear is when to use one of these tools instead of another. This is a bit awkward, given that there is a bit more overlap (and the existing documentation is less clear), but comparing the "calling this specific kernel function incorrectly is causing this very specific bug" nature of Coccinelle with the "there's a bunch of typechecking so you can statically prove you didn't forget an endianness conversion somewhere" things sparse does. (Take those with a grain of salt, though, as I confess to not being an expert with any of these tools...) I've added a few other ideas inline, below, which you can take or leave as you see fit. Either way, I think this is a great improvement on not talking about static analysis tools at all, so thanks. Reviewed-by: David Gow <davidgow@xxxxxxxxxx> Cheers, -- David > Documentation/dev-tools/testing-overview.rst | 29 ++++++++++++++++++++ > 1 file changed, 29 insertions(+) > > diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst > index 65feb81edb14..b00511109a9d 100644 > --- a/Documentation/dev-tools/testing-overview.rst > +++ b/Documentation/dev-tools/testing-overview.rst > @@ -115,3 +115,32 @@ that none of these errors are occurring during the test. > Some of these tools integrate with KUnit or kselftest and will > automatically fail tests if an issue is detected. > > +Static Analysis Tools > +====================== > + > +In addition to testing a running kernel, one may also scout for bugs by > +analyzing the source code semantics. Three tools are well known for serving this > +purpose. It might be worth being a bit more explicit that these run _at compile time_. Maybe this would also be the right place to document CONFIG_WERROR? Though that is slightly different yet again... > + > +Sparse can help test the kernel by performing type-checking, lock checking, > +value range checking, in addition to reporting various errors and warnings while > +examining the code. See the Documentation/dev-tools/sparse.rst documentation > +page for details on how to use it. It'd be nice to give an example of the extended type-checking here. e.g., endianness checks: https://lwn.net/Articles/205624/ > + > +Smatch extends Sparse and provides additional checks for programming logic > +mistakes such as missing breaks in switch statements, unused return values on > +error checking, forgetting to set an error code in the return of an error path, > +etc. Smatch also has tests against more serious issues such as integer > +overflows, null pointer dereferences, and memory leaks. See the project page at > +http://smatch.sourceforge.net/. > + > +We also have Coccinelle as an option within static analyzers. Coccinelle is Nit: _maybe_ it's worth simplifying this to just "Coccinelle is another static analyzer" or similar, so that all of these paragraphs start with the name of the tool being talked about. That makes it a bit easier to skim the page. > +often used to aid collateral evolution of source code, but it can also help to Nit: It's not entirely obvious what "collateral evolution of source code" is. Would "refactoring" be close enough? > +avoid certain bugs that have been expressed semantically. The types of tests > +available include API tests, tests for correct usage of kernel iterators, checks > +for the soundness of free operations, analysis of locking behavior, and further > +tests known to help keep consistent kernel usage. See the > +Documentation/dev-tools/coccinelle.rst documentation page for details. Maybe talk about how Coccinelle is matching specific (and often kernel-specific) patterns? > + > +These static analysis tools support running tests on the whole source tree or > +over a specific file or directory. > -- > 2.35.1 >
