Linux Kernel v6.17 is Released: This is What's New for Compute Express Link (CXL)

Linux Kernel v6.17 is Released: This is What's New for Compute Express Link (CXL)

The Linux Kernel v6.17 release brings several improvements and additions related to Compute Express Link (CXL) technology.

Release Highlights

Linux Kernel v6.17 includes 32 commits to the CXL and DAX subsystems:

CategoryCommits
New Features & Hardware1
Bug Fixes6
Refactoring & Cleanup3
Other22

The v6.17 cycle for CXL and DAX is a consolidation release rather than a feature-heavy one, with 32 commits that reflect the subsystem maturing around correctness, specification compliance, and architectural hygiene. The most visible theme is alignment with CXL specification revision 3.2: the Common Event Record has been updated to match the new spec, the Memory Sparing Event Record gains kernel tracing support for the first time, and additional validity checks land for corrected volatile memory error (CVME) counts in both DRAM and General Media Event Records. This work strengthens the kernel’s ability to correctly interpret and surface CXL RAS events to userspace tooling and monitoring infrastructure.

A quieter but structurally important change is the removal of core/acpi.c and the CXL core’s direct dependency on ACPI. This decoupling makes the CXL core more portable and easier to reason about — the ACPI glue now lives where it belongs rather than being tangled into the driver core. Alongside this, the node-notifier migration replaces the older memory-notifier pattern, bringing CXL memory hotplug handling in line with current kernel conventions for NUMA-aware memory event signaling.

Locking correctness receives explicit attention this cycle: both the conditional rwsem locking paths and the poison list mutex are converted to use ACQUIRE() semantics, ensuring proper memory ordering on architectures where weak ordering would otherwise permit reordering across these critical sections. Several targeted bug fixes round out the release, addressing a typo in the MCE notifier registration, an ERR_PTR vs NULL confusion in region handling, wrong DPA bounds checking for PPR operations in the EDAC path, and a format specifier mismatch for u32 values.

Key Changes

  • CXL Spec 3.2 Event Record Compliance: The Common Event Record structure is updated to match CXL spec rev 3.2, and validity checks are added for CVME counts in both DRAM and General Media Event Records, ensuring the kernel correctly handles fields that older firmware may leave unset.

  • Memory Sparing Event Record Tracing: Kernel tracepoints are added for the CXL Memory Sparing Event Record, making sparing operations visible through the standard trace_event infrastructure — essential for diagnosing DRAM sparing activity on CXL memory devices in production.

  • ACQUIRE() Locking Semantics: Conditional rwsem acquisition paths and the poison list mutex are converted to use explicit ACQUIRE() ordering, fixing potential memory ordering hazards on weakly-ordered architectures without adding unnecessary full barriers.

  • ACPI Dependency Removal from CXL Core: core/acpi.c is removed and the CXL core’s direct compile-time dependency on CONFIG_ACPI is eliminated, making the subsystem cleaner to build in non-ACPI environments and reducing coupling between platform firmware abstractions and driver internals.

  • Node-Notifier Migration: CXL switches from the legacy memory-notifier to the node-notifier interface for memory hotplug events, aligning with current kernel practice for NUMA-aware memory device management.

  • cxl_resource_contains_addr() Helper: A new helper function centralizes address-in-resource containment checks, replacing open-coded comparisons across the driver with a single, testable predicate — immediately used in the region probing path.

  • EDAC PPR DPA Fix: Incorrect DPA bounds checking in the EDAC path for Post Package Repair operations is corrected, preventing the driver from operating on wrong address ranges during repair sequences — a silent correctness bug with potential data integrity implications.

  • Region Commit/Detach Consolidation: cxl_decoder_kill_region() and cxl_region_detach() are merged into a single code path, eliminating duplicated teardown logic that was a maintenance hazard and a source of subtle divergence between the two flows.

Here is the detailed list of all commits merged into the 6.17 Kernel for CXL and DAX. This list was generated by the Linux Kernel CXL Feature Tracker .

How I Created a Custom ChatGPT Trained on the CXL Specification Documents

How I Created a Custom ChatGPT Trained on the CXL Specification Documents

If you’re working with Compute Express Link (CXL) and wish you had an AI assistant trained on all the different versions of the specification—1.0, 1.1, 2.0, 3.0, 3.1… you’re in luck.

Whether you’re a CXL device vendor, a firmware engineer, a Linux Kernel developer, a memory subsystem architect, a hardware validation engineer, or even an application developer working on CXL tools and utilities, chances are you’ve had to reference the CXL spec at some point. And if you have, you already know: these documents are dense, extremely technical, and constantly evolving.

Read More

How To Install a Mainline Linux Kernel in Ubuntu

Note: This article was updated on Thursday, July 31st, 2025 and will work with newer Ubuntu releases.

By default, Ubuntu systems run with the Ubuntu kernels provided by the Ubuntu repositories. To get unmodified upstream kernels that have new features or to confirm that upstream has fixed a specific issue, we often need to install the mainline Kernel. The mainline kernel is the most recent version of the Linux kernel released by the Linux Kernel Organization. It undergoes several stages of development, including merge windows, release candidates, and final releases. Mainline kernels are designed to offer the latest features and improvements, making them attractive to developers and power users. Kernel.org lists the available Kernel versions.

Read More
How To Set Linux CPU Scaling Governor to Max Performance

How To Set Linux CPU Scaling Governor to Max Performance

The majority of modern processors are capable of operating in a number of different clock frequency and voltage configurations, often referred to as Operating Performance Points or P-states (in ACPI terminology). As a rule, the higher the clock frequency and the higher the voltage, the more instructions can be retired by the CPU over a unit of time, but also the higher the clock frequency and the higher the voltage, the more energy is consumed over a unit of time (or the more power is drawn) by the CPU in the given P-state. Therefore there is a natural trade-off between the CPU capacity (the number of instructions that can be executed over a unit of time) and the power drawn by the CPU.

Read More