Occasionally, I will forget to link something from the mailing list in this post. To see my full mailing list activity (patches, reviews, and reports), you can view it on lore.kernel.org.
Linux kernel patches
Build errors: These are hard errors that appear for one reason or another. The first two are from a recent change in LLVM to avoid crashing the compiler (see the commit message for more details, I learned floating point literals exist in C). The third series is a resend that fixes
ARCH=hexagonallmodconfig, which is an important target for us because
ARCH=hexagonrequires LLVM. Lastly, the final series fixes a generic issue uncovered by the kernel test robot with an
Stable backports and patches: Keeping the stable kernels building is important because most people use them, rather than the development tree that we normally work against. Our CI has decent coverage of stable but we are looking to ramp that up going forward.
-Wimplicit-fallthrough: Now that
-Wimplicit-fallthroughis enabled by default for
clang-14and newer thanks to the great work of Gustavo A.R. Silva, we will be able to catch potential issues such as the one fixed by commit 652b44453ea9 (“habanalabs/gaudi: fix missing code in ECC handling”).
hwmon: (tmp401) Fix clang -Wimplicit-fallthrough in tmp401_is_visible()(
-Wuninitialized: Unfortunately, because the kernel is written in C, uninitialized variables continue to be an issue, especially since GCC’s
-Wmaybe-uninitializedhas been disabled by default since 5.7. These will continue to pop up until GCC can be fixed but it does not seem like that will occur anytime soon as it has been a deficiency for a long time; until then, we will continue to fix them.
-Wreturn-type: The kernel has this as a hard error because having a mismatched return type is clearly a bug. Unfortunately, this patch ended up being wrong, and the proper patch was applied to fixed it.
soc: ti: wkup_m3_ipc: Fix return type error in wkup_m3_rproc_boot_thread()(
Other series: Last year, we decided that LLVM 10.0.1 would be the minimum supported version for building the kernel. However, as time has gone on, the kernel has continued to stress
clangand exposed more deficiencies that had to be fixed in the compiler; some times, we work around these deficiencies but other times, such as this, we have to bump the minimum supported version to avoid invasively changing the kernel.
Bump minimum supported version of LLVM to 11.0.0(
Patch review and input
For the next sections, I link directly to my first response in the thread when possible but there are times where the link is to the main post. My responses can be seen inline by going to the bottom of the thread and clicking on my name.
Reviewing patches that are submitted is incredibly important, as it helps ensure good code quality due to catching mistakes before the patches get accepted and it can help get patches accepted faster, as some maintainers will blindly pick up patches that have been reviewed by someone that they trust.
Issue triage and reporting
The unfortunate thing about working at the intersection of two projects is we will often find bugs that are not strictly related to the project, which require some triage and reporting back to the original author of the breakage so that they can be fixed and not impact our own testing. Some of these bugs fall into that category while others are issues strictly related to this project.
This month was mostly spent focusing on getting the CI green via the application of patches from the mainline list as well as slowly increasing our coverage through trees (latest LTS, 5.15) and builds (hexagon allmodconfig).
Behind the scenes
Every day that there is a new linux-next release, I rebase and build a few different kernel trees then boot and runtime test them on several different machines, including a Raspberry Pi 3 and 4, HP desktop, ASUS laptop, and Hyper-V and VMware platforms on my workstation. This is not always visible because I do not report anything unless there is something broken but it can take up to a few hours each day, depending on the amount of churn and issues uncovered.
I wrote a blog post about one of the bugs I triaged above so that I can remember how to do it in the future, as well as show others what reducing a C file looks like.
During periods of downtime this month (i.e. not drowing in emails, triaging bugs, etc), I worked on containerizing some of my development environment. This allows me to potentially move from one development machine to another with minimal overhead, which can happen in the case of upgrading or failure, as well as have a consistent workspace, since everything is described in a
Containerfile. It makes getting access to older versions of LLVM and GCC easier as well, as I can build a container from a version of Debian or Ubuntu without actually having to run it as my host system.