[PATCH v2 0/4] Avoid running cppcheck on system headers
It turns out cppcheck has inbuilt knowledge of the C library, and isn't typically given the system headers. Avoiding doing so reduces the runtime to less than half of what it currently is. For non-obvious reasons, this change also exposes some new warnings. Some are real, one is a cppcheck bug. Fix and/or workaround these then make the change to the cppcheck options. This is based on my earlier series with clangd configuration and fixes. v2: * Dropped patches already merged * Rebased on Stefano's series of lint fixes * Add a missing #include in 1/4 and 2/4 * Adjust 3/4 not to die if close_range() is unavailable David Gibson (4): log: Only check for FALLOC_FL_COLLAPSE_RANGE availability at runtime linux_dep: Move close_range() conditional handling to linux_dep.h linux_dep: Fix CLOSE_RANGE_UNSHARE availability handling cppcheck: Don't check the system headers Makefile | 15 +-------------- linux_dep.h | 22 ++++++++++++++++++++++ log.c | 10 ++-------- util.c | 17 +++++++++++++++-- util.h | 19 ------------------- 5 files changed, 40 insertions(+), 43 deletions(-) -- 2.47.0
log.c has several #ifdefs on FALLOC_FL_COLLAPSE_RANGE that won't attempt
to use it if not defined. But even if the value is defined at compile
time, it might not be available in the runtime kernel, so we need to check
for errors from a fallocate() call and fall back to other methods.
Simplify this to only need the runtime check by using linux_dep.h to define
FALLOC_FL_COLLAPSE_RANGE if it's not in the kernel headers.
Signed-off-by: David Gibson
util.h has some #ifdefs and weak definitions to handle compatibility with
various kernel versions. Move this to linux_dep.h which handles several
other similar cases.
Signed-off-by: David Gibson
If CLOSE_RANGE_UNSHARE isn't defined, we define a fallback version of
close_range() which is a (successful) no-op. This is broken in several
ways:
* It doesn't actually fix compile if using old kernel headers, because
the caller of close_range() still directly uses CLOSE_RANGE_UNSHARE
unprotected by ifdefs
* Even if it did fix the compile, it means inconsistent behaviour between
a compile time failure to find the value (we silently don't close files)
and a runtime failure (we die with an error from close_range())
* Silently not closing the files we intend to close for security reasons
is probably not a good idea in any case
We don't want to simply error if close_range() or CLOSE_RANGE_UNSHARE isn't
available, because that would require running on kernel >= 5.9. On the
other hand there's not really any other way to flush all possible fds
leaked by the parent (close() in a loop takes over a minute). So in this
case print a warning and carry on.
As bonus this fixes a cppcheck error I see with some different options I'm
looking to apply in future.
Signed-off-by: David Gibson
We pass -I options to cppcheck so that it will find the system headers.
Then we need to pass a bunch more options to suppress the zillions of
cppcheck errors found in those headers.
It turns out, however, that it's not recommended to give the system headers
to cppcheck anyway. Instead it has built-in knowledge of the ANSI libc and
uses that as the basis of its checks. We do need to suppress
missingIncludeSystem warnings instead though.
Not bothering with the system headers makes the cppcheck runtime go from
~37s to ~14s on my machine, which is a pretty nice win.
Signed-off-by: David Gibson
On Fri, 8 Nov 2024 13:53:26 +1100
David Gibson
It turns out cppcheck has inbuilt knowledge of the C library, and isn't typically given the system headers. Avoiding doing so reduces the runtime to less than half of what it currently is.
For non-obvious reasons, this change also exposes some new warnings. Some are real, one is a cppcheck bug. Fix and/or workaround these then make the change to the cppcheck options.
This is based on my earlier series with clangd configuration and fixes.
Applied. -- Stefano
participants (2)
-
David Gibson
-
Stefano Brivio