Thread (19 messages) 19 messages, 2 authors, 17d ago

Re: [PATCH RFC 00/10] KVM: Enable Clang Context Analysis

From: Marco Elver <elver@google.com>
Date: 2026-09-10 19:20:25
Also in: kvm, lkml

On Thu, 10 Sept 2026 at 18:55, Sean Christopherson [off-list ref] wrote:
On Thu, Sep 10, 2026, Marco Elver wrote:
quoted
Enable compiler-based static context analysis [1] for x86 KVM, along with
prerequisite lock annotations in virt/kvm.

During the initial annotation pass, context analysis uncovered a missing
SRCU read-side critical section in x86 PMU filter lookups; patch 1 fixes
this bug.

The remainder of the series is strictly non-functional: it establishes
basic function annotations, guarded_by annotations on core structs, and
straightforward refactorings in hva/gfn range walks and guest_memfd to
eliminate conditional locking patterns that cannot be tracked statically.

Annotating the MMU (mmu/mmu.c, mmu/tdp_mmu.c), i8259, and Xen requires
more invasive changes and is deferred to follow-ups.

[1] https://docs.kernel.org/next/dev-tools/context-analysis.html
...
quoted
 43 files changed, 745 insertions(+), 236 deletions(-)
For me, there needs to be a _lot_ more explanation of what this buys us to justify
the extra annotations and ongoing maintenance burden.  And to a lesser extent, why
we should rework code to play nice with context analysis
Patch 1 is an example of what this buys: static checking shifts left
and prevents bugs from actually being committed. Context analysis can
be seen as an extension of kernel C, improving its safety, and the
nice thing is it can be enabled incrementally (no rewrites in other
languages needed, though yielding modest safety gains at a fraction of
the cost). A side-effect is compiler-checked documentation
(annotations), which helps humans and robots reading & writing kernel
code.

The question is simple: is the cost of ongoing maintenance with
context analysis greater than the cost of the bugs it prevents?
(I assume we can simply
opt-out on a per-function basis if we don't want to play nice?).
Yes with __context_unsafe(/* explanation */) attribute, or
context_unsafe(...) expressions.
I'd also like to see what the MMU changes look like before committing to supporting
this.
If you're not entirely opposed, a v2 can include that.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help