Linux kernel patches

  • tools: compiler-gcc.h: Guard error attribute use with __has_attribute (v1): The minimum version of GCC was raised to 5.1, which helped simplify a lot of code but caused issues for older versions of clang. This helps resolve it.

  • Harden clang against unknown flag options (v2): A follow up.

  • ptp: ocp: Avoid operator precedence warning in ptp_ocp_summary_show() (v1, v2): An interesting warning around operator precedence, which will not be an issue in practice but now that Linus has decreed that warnings are unacceptable, it is important to clean them up!

  • locking/ww-mutex: Fix uninitialized use of ret in test_aa() (v1): More uninitialized variable usage biting us because GCC’s warning is turned off for the kernel.

  • kasan: Always respect CONFIG_KASAN_STACK (v1): Clang’s asan-stack parameter shows high stack usage so it has been disabled but RISC-V’s implementation was not respecting that so this patch resolves that, meaning RISC-V’s allmodconfig target now builds completely clean with clang. asan-stack has been a topic of recent conversation so hopefully that can be resolved soon.

  • drm/kmb: Remove set_test_mode_src_osc_freq_target_{hi,low}_bits() (v1): Intel’s kernel test robot exposed a couple of instances of unused inline functions, which GCC will never warn about. Cleaning up dead code always helps with maintainability in the long run.

  • drm/amd: Guard IS_OLD_GCC assignment with CONFIG_CC_IS_GCC (v1): An instance where clang’s fake GCC version of 4.2.1 caused problems for us. Hopefully as time goes on, we will run into less of these as more people test with clang.

  • drm/amd: Initialize remove_mpcc in dcn201_update_mpcc() (v1): Another uninitialized warning…

  • drm/amd: Return NULL instead of false in dcn201_acquire_idle_pipe_for_layer() (v1): Returning 0 or false when the function returns a pointer will cause a clang warning so that you either use NULL or change the value, just to make sure that is what was intended.

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

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.

  • This month, we had a few conferences: the LLVM Distributors Conference, the ClangBuiltLinux meetup, and Linux Plumbers Conference. It was super helpful for interfacing with the greater LLVM and Linux kernel community and reorient ourselves going into the next year. I gave a talk at the ClangBuiltLinux meetup around our continuous integration.

Special thanks to: