Kernel & Embedded News: KWatch Watchpoint Tool; RISC-V Cache QoS

An RFC for dynamic hardware watchpoints, RISC-V Ssqosid and CBQRI cache QoS, BPF shields against kernel exploits, a lockless MPSC queue in io_uring, and Linux 7.2-rc3.

The common thread this edition is control over a running kernel: knowing which instruction wrote to an address, deciding which workload gets cache capacity, and blocking an exploit before a patch is available. Each of these arrives from a different subsystem, but they all address problems that embedded and systems teams meet in production rather than in the lab. Three of the five are still proposals, so the practical value is in understanding the direction, not in shipping them next week.

In this edition

• KWatch: dynamic hardware watchpoints. Jinchao Wang posted an RFC series adding mm/kwatch, which arms a hardware breakpoint only while a chosen function runs and reports the writer of a corrupted address through a tracepoint.
• RISC-V cache QoS reaches v5. Drew Fustini posted version 5 of the Ssqosid and CBQRI series, which brings RISC-V cache capacity allocation under the existing resctrl filesystem.
• BPF programs as exploit shields. John Fastabend described at LSFMM+BPF 2026 how Cisco uses BPF programs to block kernel exploits across many kernel versions instead of writing per-branch live patches.
• io_uring moves to a lockless queue. The 7.2 kernel replaces io_uring’s linked-list task tracking with a lockless multi-producer, single-consumer queue.
• Linux 7.2-rc3 released. Linus Torvalds released 7.2-rc3 on 12 July, with UltraRISC enabled in the RISC-V default configuration and a hardening fix for the Realtek RTL8723BS driver.

KWatch: finding the writer, not the victim

Jinchao Wang’s RFC series adds a facility called KWatch under mm/kwatch. It targets a specific class of bug: a valid pointer used at the wrong time, or a stale pointer that overwrites a live object. The crash then happens somewhere else entirely, in code that did nothing wrong.

The reason this class is expensive is that existing tools do not see it. KASAN and KFENCE detect invalid accesses; an in-bounds write through a legitimate pointer never violates memory safety, so they stay silent. Hardware watchpoints through kgdb or perf can watch one fixed address for the whole run, but the address you care about is usually per-object and per-invocation.

KWatch works around the scarcity of breakpoint registers — x86 has four slots per CPU — by scoping the watch to a function. A kretprobe pair opens the window at function entry and closes it on return, and a per-CPU hardware breakpoint from a preallocated pool is pointed at an address resolved from an expression. The expression can start from a function argument, the stack pointer, a symbol or an absolute address, with offsets and pointer dereferences chained on top.

The series includes a real case. Gadget requests in dummy_hcd were completing through a clobbered req->complete, and months of KASAN-enabled syzkaller runs produced only downstream symptoms. A single debugfs line watching arg2+56 of usb_gadget_giveback_request caught memcpy writing to the field, with the full stack trace of the caller. The root cause was a shared fifo_req being struct-copied while another path was mid-giveback — neither a use-after-free nor list corruption, so the existing checkers were blind to it by design.

Read the design document even though this is an RFC and x86-only for now; arm64 needs single-stepping support that does not exist yet for in-kernel breakpoint consumers. The value for anyone doing driver work is the technique itself. Most engineers reach for printk and bisection when a structure field is being corrupted, and both are slow. Knowing that a function-scoped hardware watchpoint is possible changes how you approach the next corruption you cannot attribute.

RISC-V gains cache partitioning through resctrl

Drew Fustini’s v5 series adds initial RISC-V quality-of-service support: the Ssqosid extension with its srmcfg CSR, the CBQRI controller interface wired into resctrl, and a device-tree platform driver for cache controllers. It has been tested on the Tenstorrent Ascalon shared cache controller and on a QEMU implementation.

The interface is the existing one. Mount resctrl, read the schemata, and write a narrower capacity bitmask to a control group:

# mount -t resctrl resctrl /sys/fs/resctrl
# cat /sys/fs/resctrl/schemata
L2:0=ffff
# mkdir /sys/fs/resctrl/group0
# echo "L2:0=ff" > /sys/fs/resctrl/group0/schemata

This matters more for embedded work than the RISC-V label suggests. Cache partitioning is how you stop a background workload from evicting the working set of a latency-sensitive one, and that is a recurring problem in mixed-criticality designs where a control loop shares silicon with a video pipeline or an inference task. Until now, that control was an x86 and Arm concern.

Note the scope carefully before planning around it. This series implements only L2 and L3 capacity allocation via CBQRI capacity block masks; capacity monitoring and bandwidth allocation are not included, because CBQRI’s bandwidth controls do not map onto resctrl’s throttle-based MB schema. Fustini states that the full implementation will be rebased onto Reinette Chatre’s generic schema description once it is ready. Treat cache allocation on RISC-V as available in prototype form and monitoring as pending.

BPF programs proposed as temporary exploit shields

At the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit, John Fastabend described Cisco’s approach to a problem many product companies share: many concurrent product lines, each on a different stable kernel with local modifications, and a vulnerability that has to be handled on all of them at once.

Live patching can do this, but a live patch is written against one kernel tree. Across a large product matrix, that is a separate development effort per branch. A BPF program that blocks the conditions an exploit needs can usually run unchanged across all the supported kernels, which shortens the time between disclosure and mitigation considerably.

Fastabend was direct about the limitation: the technique is not fully effective unless more hooks are added to the kernel. You can only shield what you can attach to, and the current hook coverage does not reach every place a mitigation would need.

For teams under Cyber Resilience Act obligations, the reason to follow this is the gap it fills. Regulatory timelines measure the response to a known vulnerability, and a full BSP rebuild plus field update rarely fits inside them. A mechanism that reduces exposure while the real fix moves through your build and validation process is worth understanding, even if you do not adopt it. It does not replace the patch; it provides the time to apply one properly.

io_uring switches to a lockless MPSC queue in 7.2

io_uring keeps many operations in flight at once, and it has to track the work items associated with them. Current kernels use a standard kernel linked-list primitive for this. As of 7.2, io_uring instead uses a new lockless multi-producer, single-consumer queue, with notable performance gains.

Applications need no changes; the queue is internal. The gain shows up where many producers submit work concurrently, which is exactly the pattern io_uring exists to serve.

The algorithm is worth reading for its own sake. Lockless code is usually hard to follow, and this one is approachable enough to serve as a working example of how multi-producer, single-consumer structures are built in kernel code. Anyone who has been told to use a lock-free queue without being shown one should spend an hour with it.

Linux 7.2-rc3 keeps the cycle on schedule

Linus Torvalds released 7.2-rc3 on 12 July, describing the cycle as the “new normal” with slightly higher commit rates, partly balanced by summer vacations. About half the changes are driver fixes, spread across the tree, and in his words nothing looks particularly scary or strange.

Two items in rc3 are relevant to embedded builds. UltraRISC support is now enabled in the RISC-V default kernel configuration, which removes a manual step for anyone testing that silicon. The Realtek RTL8723BS driver received an out-of-bounds read fix that hardens it against malicious access points — a driver still common on low-cost boards, so check whether your BSP carries it.

Stable 7.2 is expected in the second half of August. If you plan to evaluate it, the rc phase is when your board-specific problems are cheapest to report and fix; waiting for the release means competing for maintainer attention with everyone else who waited.

References

• mm/kwatch: dynamic hardware watchpoints for hunting memory corruption (RFC, LWN patch archive)
• riscv: Add Ssqosid and initial CBQRI resctrl support, v5 (LWN patch archive)
• Shielding running kernels against exploits with BPF (LWN)
• Lockless MPSC FIFO queues for io_uring (LWN)
• Linux 7.2-rc3 Released: Close To The “New Normal” (Phoronix)
• Linux 7.2 Enabling UltraRISC RISC-V Support In The Default Kernel Build (Phoronix)
• Realtek RTL8723BS WiFi Linux Driver Hardened Against Malicious WiFi Access Points (Phoronix)
• User Interface for Resource Control feature (kernel documentation)
• Kernel coverage at LWN.net

— Raghu Bharadwaj