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

  • Miscellaneous improvements: These are series or patches that do not really fit into any of the other categories I typically use with my reports.

    • Allow CONFIG_DEBUG_INFO_DWARF5=y + CONFIG_DEBUG_INFO_BTF=y (v1)
    • tools/resolve_btfids: Do not print any commands when building silently (v1)

  • -Wenum-conversion: This warning occurs when one enumerated type is implicitly converted to another enumerated type, which is typically a bug, although it might not actually be a problem in practice if the used enum has the same value as the intended enum (which is the case here). It is still good to get it corrected, as the enums might not stay in sync.

    • drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (v1)

  • -Wimplicit-fallthrough: Clang’s -Wimplicit-fallthrough (enabled in commit dee2b702bcf0 (“kconfig: Add support for -Wimplicit-fallthrough”)) is more pedantic than GCC’s version, requiring all case statements to have a fallthrough annotation, not just ones that do not fallthrough to break or return. Clang’s version matches the kernel’s preference for switch statements, so keeping the kernel clean of these warnings is important, in case GCC ever allows a mode that conforms to the kernel’s preference.

    • lib/maple_tree: Fix clang -Wimplicit-fallthrough in mte_set_pivot() (v1)

  • -Wunaligned-access: This is a new warning introduced in clang-14 to help catch unaligned accesses on ARM, which can be expensive, as they have to go through the exception handler for fixups. The warning is quite noisy, so we shut it up for default builds, but we allow it to show up for W=1 to help prevent new instances from creeping in. This should eventually be enabled for default builds as well but cleaning up the instances will take time.

  • -Wunitialized / -Wsometimes-uninitialized: As always, Clang will catch uninitialized variables because GCC’s version of the warning was moved to W=2, which people rarely test with, due to the noise.

    • io_uring: Fix use of uninitialized ret in io_eventfd_register() (v1)
    • drm/stm: Avoid using val uninitialized in ltdc_set_ycbcr_config() (v1, v2)
    • iio: accel: adxl367: Fix handled initialization in adxl367_irq_handler() (v1)

  • -Wunneeded-internal-declaration: This is a really interesting warning that only Clang appears to have. When a variable is only used in a compile time expression (such as in sizeof() or typeof()), clang will warn about it, as the programmer might have intended to use it elsewhere. In this particular case, it is expected, but there have been other times where it is clearly a bug.

    • mm/page_alloc: Mark pagesets as __maybe_unused (v1)

  • -Wunused-function: This is not typically a Clang specific warning but in this case, only Clang caught it because GCC does not warn on static inline functions in .c files, whereas Clang does. We make Clang match GCC for a default build but Masahiro Yamada changed that behavior for W=1 to help clean up or fix unused code.

    • ftrace: Remove unused ftrace_startup_enable() stub (v1)

  • -Wunused-variable: Another warning that is not Clang specific but it impacts our builds just like GCC so it is important to clean them up.

    • proc: Avoid unused variable warning in pagemap_pmd_range() (v1)

  • -Wvisibility: This warning merely tells a developer that they have declared a type within a function, which cannot be used outside of the function. GCC has a similar warning, and like the past few warnings, it is important to fix all warnings that appear.

    • thermal: netlink: Fix parameter type of thermal_genl_cpu_capability_event() stub (v1)

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 Windows Subsystem for Linux instance, a Raspberry Pi 3 and 4, 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.

Special thanks to: