linux.git - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author
2021-02-16	gen_compile_commands: prune some directories	Masahiro Yamada
	If directories are passed to gen_compile_commands.py, os.walk() traverses all the subdirectories to search for .cmd files, but we know some of them are not worth traversing. Use the 'topdown' parameter of os.walk to prune them. Documentation about the 'topdown' option of os.walk: When topdown is True, the caller can modify the dirnames list in-place (perhaps using del or slice assignment), and walk() will only recurse into the subdirectories whose names remain in dirnames; this can be used to prune the search, impose a specific order of visiting, or even to inform walk() about directories the caller creates or renames before it resumes walk() again. Modifying dirnames when topdown is False has no effect on the behavior of the walk, because in bottom-up mode the directories in dirnames are generated before dirpath itself is generated. This commit prunes four directories, .git, Documentation, include, and tools. The first three do not contain any C files, so skipping them makes this script work slightly faster. My main motivation is the last one, tools/ directory. Commit 6ca4c6d25949 ("gen_compile_commands: do not support .cmd files under tools/ directory") stopped supporting the tools/ directory. The current code no longer picks up .cmd files from the tools/ directory. If you run: ./scripts/clang-tools/gen_compile_commands.py --log_level=INFO then, you will see several "File ... not found" log messages. This is expected, and I do not want to support the tools/ directory. However, without an explicit comment "do not support tools/", somebody might try to get it back. Clarify this. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Nathan Chancellor <nathan@kernel.org>
2021-02-03	scripts/clang-tools: switch explicitly to Python 3	Masahiro Yamada
	For the same reason as commit 51839e29cb59 ("scripts: switch explicitly to Python 3"), switch some more scripts, which I tested and confirmed working on Python 3. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Nathan Chancellor <nathan@kernel.org>
2020-08-27	Makefile: Add clang-tidy and static analyzer support to makefile	Nathan Huckleberry
	This patch adds clang-tidy and the clang static-analyzer as make targets. The goal of this patch is to make static analysis tools usable and extendable by any developer or researcher who is familiar with basic c++. The current static analysis tools require intimate knowledge of the internal workings of the static analysis. Clang-tidy and the clang static analyzers expose an easy to use api and allow users unfamiliar with clang to write new checks with relative ease. ===Clang-tidy=== Clang-tidy is an easily extendable 'linter' that runs on the AST. Clang-tidy checks are easy to write and understand. A check consists of two parts, a matcher and a checker. The matcher is created using a domain specific language that acts on the AST (https://clang.llvm.org/docs/LibASTMatchersReference.html). When AST nodes are found by the matcher a callback is made to the checker. The checker can then execute additional checks and issue warnings. Here is an example clang-tidy check to report functions that have calls to local_irq_disable without calls to local_irq_enable and vice-versa. Functions flagged with __attribute((annotation("ignore_irq_balancing"))) are ignored for analysis. (https://reviews.llvm.org/D65828) ===Clang static analyzer=== The clang static analyzer is a more powerful static analysis tool that uses symbolic execution to find bugs. Currently there is a check that looks for potential security bugs from invalid uses of kmalloc and kfree. There are several more general purpose checks that are useful for the kernel. The clang static analyzer is well documented and designed to be extensible. (https://clang-analyzer.llvm.org/checker_dev_manual.html) (https://github.com/haoNoQ/clang-analyzer-guide/releases/download/v0.1/clang-analyzer-guide-v0.1.pdf) The main draw of the clang tools is how accessible they are. The clang documentation is very nice and these tools are built specifically to be easily extendable by any developer. They provide an accessible method of bug-finding and research to people who are not overly familiar with the kernel codebase. Signed-off-by: Nathan Huckleberry <nhuck@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>