From 12379401c000495e683c5c5574b82a64f8d826d6 Mon Sep 17 00:00:00 2001 From: Marcelo Schmitt Date: Wed, 30 Mar 2022 18:49:33 -0300 Subject: Documentation: dev-tools: Add a section for static analysis tools Complement the Kernel Testing Guide documentation page by adding a section about static analysis tools. Signed-off-by: Marcelo Schmitt Acked-by: Daniel Latypov Acked-by: Dan Carpenter Acked-by: Julia Lawall Reviewed-by: David Gow Reviewed-by: Shuah Khan Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/testing-overview.rst | 31 ++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'Documentation/dev-tools') diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index 65feb81edb14..b5e02dd3fd94 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -115,3 +115,34 @@ 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 can also analyze kernel source code +directly (**at compile time**) using **static analysis** tools. The tools +commonly used in the kernel allow one to inspect the whole source tree or just +specific files within it. They make it easier to detect and fix problems during +the development process. + +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. + +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/. + +Coccinelle is another static analyzer at our disposal. Coccinelle is often used +to aid refactoring and collateral evolution of source code, but it can also help +to avoid certain bugs that occur in common code patterns. 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. + +Beware, though, that static analysis tools suffer from **false positives**. +Errors and warns need to be evaluated carefully before attempting to fix them. -- cgit From a32d5c0fc12b1dec44ddd97434cbb0203c7e60e5 Mon Sep 17 00:00:00 2001 From: Marcelo Schmitt Date: Wed, 30 Mar 2022 18:49:59 -0300 Subject: Documentation: dev-tools: Enhance static analysis section with discussion Enhance the static analysis tools section with a discussion on when to use each of them. This was mainly taken from Dan Carpenter and Julia Lawall's comments on a previous documentation patch for static analysis tools. Lore: https://lore.kernel.org/linux-doc/20220329090911.GX3293@kadam/T/#mb97770c8e938095aadc3ee08f4ac7fe32ae386e6 Signed-off-by: Marcelo Schmitt Acked-by: David Gow Cc: Dan Carpenter Cc: Julia Lawall Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/testing-overview.rst | 32 ++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation/dev-tools') diff --git a/Documentation/dev-tools/testing-overview.rst b/Documentation/dev-tools/testing-overview.rst index b5e02dd3fd94..0aaf6ea53608 100644 --- a/Documentation/dev-tools/testing-overview.rst +++ b/Documentation/dev-tools/testing-overview.rst @@ -146,3 +146,35 @@ Documentation/dev-tools/coccinelle.rst documentation page for details. Beware, though, that static analysis tools suffer from **false positives**. Errors and warns need to be evaluated carefully before attempting to fix them. + +When to use Sparse and Smatch +----------------------------- + +Sparse does type checking, such as verifying that annotated variables do not +cause endianness bugs, detecting places that use ``__user`` pointers improperly, +and analyzing the compatibility of symbol initializers. + +Smatch does flow analysis and, if allowed to build the function database, it +also does cross function analysis. Smatch tries to answer questions like where +is this buffer allocated? How big is it? Can this index be controlled by the +user? Is this variable larger than that variable? + +It's generally easier to write checks in Smatch than it is to write checks in +Sparse. Nevertheless, there are some overlaps between Sparse and Smatch checks. + +Strong points of Smatch and Coccinelle +-------------------------------------- + +Coccinelle is probably the easiest for writing checks. It works before the +pre-processor so it's easier to check for bugs in macros using Coccinelle. +Coccinelle also creates patches for you, which no other tool does. + +For example, with Coccinelle you can do a mass conversion from +``kmalloc(x * size, GFP_KERNEL)`` to ``kmalloc_array(x, size, GFP_KERNEL)``, and +that's really useful. If you just created a Smatch warning and try to push the +work of converting on to the maintainers they would be annoyed. You'd have to +argue about each warning if can really overflow or not. + +Coccinelle does no analysis of variable values, which is the strong point of +Smatch. On the other hand, Coccinelle allows you to do simple things in a simple +way. -- cgit From 77930ee4d5b35e4a88a33e83fe8bf91a7a7016f9 Mon Sep 17 00:00:00 2001 From: Andreas-Christian Hagau Date: Sun, 17 Apr 2022 10:37:51 +0200 Subject: Documentation: kunit: change complete_and_exit to kthread_complete_and_exit Commit cead18552660 ("exit: Rename complete_and_exit to kthread_complete_and_exit") renamed complete_and_exit to kthread_complete_and_exit. Signed-off-by: Andreas-Christian Hagau Reviewed-by: Brendan Higgins Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kunit/architecture.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/dev-tools') diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index ff9c85a0bff2..cf9e6e3eeae4 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -125,7 +125,7 @@ All expectations/assertions are formatted as: ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. - ``kunit_try_catch_throw`` calls function: - ``void complete_and_exit(struct completion *, long) __noreturn;`` + ``void kthread_complete_and_exit(struct completion *, long) __noreturn;`` and terminates the special thread context. - ```` denotes a check with options: ``TRUE`` (supplied property -- cgit From 62ce577b9887accea6f65422f593e83b266a8bf0 Mon Sep 17 00:00:00 2001 From: Frank Rowand Date: Wed, 16 Mar 2022 15:26:22 -0500 Subject: Documentation: dev-tools: use literal block instead of code-block KTAP Specification: Change code-block directives to straightforward literal blocks since the blocks do not contain code. Suggested-by: Jonathan Corbet Signed-off-by: Frank Rowand Reviewed-by: David Gow Link: https://lore.kernel.org/r/20220316202622.324866-3-frowand.list@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/ktap.rst | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'Documentation/dev-tools') diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst index 5ee735c6687f..d0a9565b0f44 100644 --- a/Documentation/dev-tools/ktap.rst +++ b/Documentation/dev-tools/ktap.rst @@ -115,34 +115,32 @@ The diagnostic data field is optional, and results which have neither a directive nor any diagnostic data do not need to include the "#" field separator. -Example result lines include: - -.. code-block:: none +Example result lines include:: ok 1 test_case_name The test "test_case_name" passed. -.. code-block:: none +:: not ok 1 test_case_name The test "test_case_name" failed. -.. code-block:: none +:: ok 1 test # SKIP necessary dependency unavailable The test "test" was SKIPPED with the diagnostic message "necessary dependency unavailable". -.. code-block:: none +:: not ok 1 test # TIMEOUT 30 seconds The test "test" timed out, with diagnostic data "30 seconds". -.. code-block:: none +:: ok 5 check return code # rcode=0 @@ -202,7 +200,7 @@ allowed to be either indented or not indented. An example of a test with two nested subtests: -.. code-block:: none +:: KTAP version 1 1..1 @@ -215,7 +213,7 @@ An example of a test with two nested subtests: An example format with multiple levels of nested testing: -.. code-block:: none +:: KTAP version 1 1..2 @@ -250,7 +248,7 @@ nested version line, uses a line of the form Example KTAP output -------------------- -.. code-block:: none +:: KTAP version 1 1..1 -- cgit