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 :)

    • RISC-V: vdso: Do not add missing symbols to version section in linker script (v1)
    • x86/vdso: Conditionally export __vdso_sgx_enter_enclave (v1)

  • CFI fixes: Kernel Control Flow Integrity (kCFI) was recently merged into mainline so it is important to keep the kernel free of new CFI failures. A new warning in clang will flag this so these patches fix all the warnings so that we turn it on and have all the automation warn people when they introduce a new instance of the warning.

    • drm/amdgpu: Fix type of second parameter in trans_msg() callback (v1)
    • drm/amdgpu: Fix type of second parameter in odn_edit_dpm_table() callback (v1)
    • drm/fsl-dcu: Fix return type of fsl_dcu_drm_connector_mode_valid() (v1)
    • drm/mediatek: Fix return type of mtk_hdmi_bridge_mode_valid() (v1)
    • drm/meson: Fix return type of meson_encoder_cvbs_mode_valid() (v1)
    • drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid() (v1)
    • HSI: ssi_protocol: Fix return type of ssip_pn_xmit() (v1)
    • hamradio: baycom_epp: Fix return type of baycom_send_packet() (v1)
    • net: ethernet: ti: Fix return type of netcp_ndo_start_xmit() (v1)
    • scsi: elx: libefc: Fix second parameter type in state callbacks (v1)
    • s390/ctcm: Fix return type of ctc{mp,}m_tx() (v1, v2)
    • s390/netiucv: Fix return type of netiucv_tx() (v1, v2)
    • s390/lcs: Fix return type of lcs_start_xmit() (v1, v2)
    • counter: Adjust final parameter type in function and signal callbacks (v1)
    • counter: stm32-timer-cnt: Adjust final parameter type of stm32_count_direction_read() (v1)
    • counter: ti-ecap-capture: Adjust final parameter type of ecap_cnt_pol_{read,write}() (v1)
    • counter: 104-quad-8: Adjust final parameter type of certain callback functions (v1)
    • net: ethernet: renesas: Fix return type of rswitch_start_xmit() (v1)
    • drm: xlnx: Fix return type of zynqmp_dp_bridge_mode_valid (v2)
    • net: mana: Fix return type of mana_start_xmit() (v3)

  • Miscellaneous fixes: These are fixes and improvements that don’t fit into a particular category but are important to ClangBuiltLinux.

    • vmlinux.lds.h: Fix placement of '.data..decrypted' section (v1)
    • Fix lack of section mismatch warnings with LTO (v1

  • 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…

    • bpf: Add explicit cast to 'void *' for __BPF_DISPATCHER_UPDATE() (v1)
    • cpufreq: ACPI: Remove unused variables 'acpi_cpufreq_online' and 'ret' (v1)
    • ARM: Drop '-mthumb' from AFLAGS_ISA (v1, v2)
    • media: rzg2l-cru: Remove unnecessary shadowing of ret in rzg2l_csi2_s_stream() (v1)
    • mm: Fix '.data.once' orphan section warning (v1)

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, 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.

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.

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 Windows Subsystem for Linux instance, a Raspberry Pi 3 and 4, an Intel-based desktop, an AMD-based desktop, an Intel-based laptop, and a SolidRun Honeycomb LX2. 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 ran two ClangBuiltLinux meetings this month, which involves reporting what happened in the past two weeks to people who might not follow the project that closes. I review emails and issues to sumarize everything clearly.

  • I spent some time during the quieter parts of the month improving my personal automation for tasks such as writing these reports and setting up test/virtual machines and spot instance servers to be more robust and easier to maintain, modify, and debug. It makes me more confident in making sure the steps complete without any problems.

Special thanks to: