Linux kernel patches

  • [PATCH] Hexagon: Export raw I/O routines for modules: Hexagon is a digital signal processor architecture by Qualcomm, which is a little special in terms of the Linux kernel because it is the only architecture that does not have a GCC backend so LLVM has to be used to build it, meaning that it is important to keep it building. This patch fixes an issue with allmodconfig, which enables us to build a wide variety of code and verify the compiler is able to handle all of it.

  • [PATCH] arm64: Restrict ARM64_BTI_KERNEL to clang 12.0.0 and newer: There was an issue with LLVM’s implementation of ARM’s Branch Target Identification, a feature of the ARMv8.5 instruction set, which causes a lot of warnings for clang 11.x. To clear up the build, we just disable this option so that users who need access to it will just upgrade their toolchains.

  • ANDROID: generate_initcall_order.pl: Use two dash long options for llvm-nm: This was an Android specific issue that impacted our CI due to an upstream LLVM change. The benefit of doing this in Android’s kernel/common tree now is that their update to LLVM 13.x+ will be smooth and all Android devices that track it (which is the majority of devices being updated in the wild) will automatically get that change, resulting in one less bug to triage.

  • [PATCH 4.9 1/2] iommu/amd: Fix backport of 140456f994195b568ecd7fc2287a34eadffef3ca and [PATCH 4.9 2/2] tipc: Fix backport of b77413446408fdd256599daf00d5be72b5f3e7c6: A series of fixes for the 4.9 series of kernels, which Intel’s kernel test robot notified us about. The first one is less likely to happen but I am very surprised nobody reported any issues with the second commit considering the pointer is completely uninitialized. It is important to monitor backports because the kernel moves so rapidly that it is easy to make these kinds of contextual mistakes.

  • [PATCH] drm/exynos: Always initialize mapping in exynos_drm_register_dma(): A build warning that is harmless in the vast majority of configurations because the hardware that this driver will actually be running on will have one of the two IOMMU configs enabled but it is important to clean up build warnings so that actual issues can be easily caught.

  • [PATCH] hexagon: Clean up timer-regs.h: A build warning that was noticed with ARCH=hexagon allmodconfig, which builds a large amount of the kernel. This target has uncovered two bugs in the Hexagon backend in LLVM so it is important to keep it as warning free as possible so that errors can be easily caught.

  • [PATCH] bsg: Fix build error with CONFIG_BLK_DEV_BSG_COMMON=m: This was not a bug as a result of clang in and of itself but it did impact my ability to build OpenSUSE’s config for i386, which I am trying to enable in our CI to increase build coverage. This patch was not accepted as struct bsg_class_device was removed in a subsequent patch so this is only a bisect risk.

  • [[PATCH] vmlinux.lds.h: Handle clang's module.{c,d}tor sections](https://lore.kernel.org/r/20210730223815.1382706-1-nathan@kernel.org/): A change in LLVM causes .text.asan.module_ctor, .text.asan.module_d tor, and .text.tsan.module_ctor` sections to appear, which have to be explicitly handled in the kernel’s linker script to avoid warnings with the linker. As it turns out, not handling them results in panics while running the KASAN KUnit tests, which is usually explained by the fact that the linker can choose to stick the section wherever and if there is a call to it in a section that is too far away, the call goes off into nowhere.

LLVM patches

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.

Tooling improvements

We maintain a few different repos that help make our lives easier, such as toolchain build scripts, QEMU wrapper scripts, and continuous integration so that we catch and triage issues sooner.

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.

  • There are times where I have to test a patch series behind the scenes, which results in a Tested-by: tag in the end but no public mailing list posts. This month, that happened with Will Deacon’s series here.

Special thanks to: