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 patches to fix various build errors that I found through testing different configurations with LLVM or were exposed by our continuous integration setup. The kernel needs to build in order to be run :)
-
Miscellaneous fixes and improvements: These are fixes and improvements that don’t fit into a particular category but are important to ClangBuiltLinux.
-
Warning fixes: These are patches to fix various warnings that appear with LLVM. I used to go into detail about the different warnings and what they mean, but the important takeaway for this section is that the kernel should build warning free, as all developers should be using
CONFIG_WERROR
, which will turn these all into failures. Maybe these should be in the build failures section…
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.
Re: [PATCH] drm/vblank: Fix for drivers that do not drm_vblank_init()
Re: [PATCH] kbuild: clang: do not use CROSS_COMPILE for target triple
Re: [PATCH v2] drm/vblank: Fix for drivers that do not drm_vblank_init()
Re: [PATCH] scripts: rust: drop is_rust_module.sh
Re: [PATCH 1/3] kbuild: merge cmd_archive_linux and cmd_archive_perf
Re: [PATCH 2/3] kbuild: do not create intermediate *.tar for source tarballs
Re: [PATCH 3/3] kbuild: do not create intermediate *.tar for tar packages
Re: [PATCH 1/5] MIPS: Move various toolchain ASE check to Kconfig
Re: [PATCH] ubsan: remove cc-option test for UBSAN_TRAP
Re: [PATCH 1/2] wifi: iwlwifi: mvm: fix the order of TIMING_MEASUREMENT notifications
Re: [PATCH] kbuild: add $(CLANG_CFLAGS) to KBUILD_CPPFLAGS
[StackProtector] don't check stack protector before calling nounwind functions
Re: [PATCH 1/2] start_kernel: add no_stack_protector fn attr
Re: [PATCH 2/2] start_kernel: omit prevent_tail_call_optimization for newer toolchains
Re: [PATCH] phy: mediatek: fix returning garbage
[CodeGen][Shrink-wrap]split restore point
Re: [PATCH] kasan: remove hwasan-kernel-mem-intrinsic-prefix=1 for clang-14
Re: [PATCH] [v2] kasan: remove hwasan-kernel-mem-intrinsic-prefix=1 for clang-14
Re: [PATCH] kbuild: rpm-pkg: remove kernel-drm PROVIDES
Re: [PATCH] staging: vchiq_arm: Make vchiq_platform_init() static
Re: [PATCH] soc: ti: pruss: Avoid cast to incompatible function type
Android rv64
Re: [PATCH v2 1/2] phy: mediatek: hdmi: mt8195: fix uninitialized variable usage in pll_calc
Re: [PATCH v2 2/7] MIPS: Add toolchain feature dependency for microMIPS smartMIPS
Re: [PATCH] scripts: Remove ICC-related dead code
Re: [PATCH] kbuild: deb-pkg: specify targets in debian/rules as .PHONY
Issue triage, input, 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.
Re: linux-next: Tree for Apr 3
Re: [PATCH] prctl: Add PR_GET_AUXV to copy auxv to userspace
Re: [stable:linux-5.4.y 5319/9999] ld.lld: error: drivers/nvme/host/core.o: contains a compressed section, but zlib is not available
[RISCV] Account for LMUL in memory op costs
MIPS: recordmcount failed to run on object file generated by IAS
Re: [PATCH] kbuild: add $(CLANG_CFLAGS) to KBUILD_CPPFLAGS
Various boot issues after LLVM commit 5f0bccc3d1a7
Re: linux-next: manual merge of the drm tree with the powerpc tree
Re: LLVM not detected in bpfutil due to LLVM 16 requiring c++17
Missing build.log for several builds
arm64 gki_defconfig boot failure on android-4.19-stable after LLVM commit 5ecd36329508
Re: arch/mips/include/asm/timex.h:75:10: error: instruction requires a CPU feature not currently enabled
Re: next: mips: ERROR: modpost: Section mismatches detected.
modpost warning from specialized __create_pgd_mapping_locked() after LLVM commit cc7bb7080fc8
"'-pcrel' / '-prefixed' is not a recognized feature for this target" when building .S files
Re: [PATCH] tty: tty_io: remove hung_up_tty_fops
Tooling improvements
These are changes to various tools that we use, such as our continuous integration setup, booting utilities, toolchain building scripts, or other closely related projects such as AOSP’s distribution of LLVM and TuxMake.
boot-qemu.py: Attempt to guess architecture from vmlinux without '-a'
Add syncpt_irq patch to android-mainline
tc_build: Switch to absolute imports
Update 64-bit big endian PowerPC configuration target
boot-qemu.py: Add file strings for aarch64 with CONFIG_RELOCATABLE=n
ruff.toml: Disable S603 and S607 (boot-utils)
ruff.toml: Disable S603 and S607 (tc-build)
patches: Drop zicsr/zifencei 5.10 backport
docker: Allow clang-android to target riscv
Disable RISC-V gki_defconfig with llvm_android for now
Fix ChromeOS boot testing
tc_build: kernel: Adjust PowerPC64 configuration target
patches: mainline: Add in-flight DRM revert to fix PowerPC breakage
Revert #559
Update stable anchor to 6.3
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 4, a Raspberry Pi 3, a SolidRun Honeycomb LX2, an Ampere Altra Developer Platform, an Intel-based desktop, an AMD-based desktop, and an Intel-based laptop. 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 uploaded LLVM 16.0.2 to kernel.org to continue to encourage developers to test with clang/LLVM.
Special thanks
Special thanks to Google and the Linux Foundation for sponsoring my work.