On Fri, 19 Dec 2025 at 22:28, Bart Van Assche <[email protected]> wrote: > > On 12/19/25 2:16 PM, Marco Elver wrote: > > It's basically an escape hatch to defer to dynamic analysis where the > > limits of the static analysis are reached. > > That's not how lockdep_assert_held() is used in the kernel.
Because there had not been any static analysis like this, and dynamic analysis is the only reasonable option. > This macro > is more often than not used to document assumptions that can be verified > at compile time. In that case the lockdep_assert can be dropped. > This patch seems like a step in the wrong direction to me because it > *suppresses* compile time analysis compile-time analysis is useful. I > think that this patch either should be dropped or that the __assume() > annotations should be changed into __must_hold() annotations. If we drop this patch, e.g. the "sched: Enable context analysis for core.c and fair.c" will no longer compile. It's a trade-off: more false positives vs. more complete analysis. For an analysis to be useful, these trade-offs make or break the analysis depending on the system they are applied to. In the kernel, our experience with developer tooling has been that any efforts to reduce false positives will help a tool succeed at scale. Later you can claw back some completeness, but focusing on completeness first will kill the tool if false positives cannot reasonably be dealt with. >From the user space world we know that "assert lock held" [1] as this kind of escape hatch is valuable to deal with cases the static analysis just can't deal with. Sure, here we can make our own rules, but I'd argue we're in a worse position than most user space code, in that kernel code is significantly more complex (which is the reason I spent over half a year banging my head to make Clang's analysis significantly more capable). [1] https://github.com/abseil/abseil-cpp/blob/a8960c053bf4adadac097c1101d0028742d8042f/absl/synchronization/mutex.h#L210 (ASSERT_EXCLUSIVE_LOCK() == __assume_ctx_lock())
