Re: [PATCH 03/14] block: Make the lock context annotations compatible with Clang

[Bart Van Assche <bvanassche@acm.org>]

On 3/4/26 2:58 PM, Tejun Heo wrote:
> I mean, yeah, static bug detection is nice but is error-prone manual
> annotation the way to do it at this time and age?

Clang verifies the consistency of the annotations with the 
implementation of the annotated function at compile time. Hence, I don't
think that these annotations can be called error-prone.

> These annotations have
> been around for as long as I can remember and I've never once found them
> genuinely useful. Sure, maybe it can flag some latent error path bugs once
> in a blue moon but for the most part they're unused and unmaintained
> appendages that just add to noise.

Agreed that these annotations were not very useful as long as sparse was
the only tool for verifying these annotations. The verification
performed by Clang however seems very useful to me.

> Here's a challenge. Can it reliably and in a sustainable manner capture
> anything that https://github.com/masoncl/review-prompts can't capture?

The above URL points at a repository with AI review prompts. Today's AI
systems are based on LLMs. LLMs suffer from the following issues, issues
that do not apply to Clang's compile-time thread-safety analysis:
* Hallucinations. This means generating grammatically perfect but
   factually incorrect statements.
* The "lost in the middle" phenomenon. Ignoring information that occurs
   in the middle of a long prompt.
* Not being built into the compiler. Clang's thread-safety analysis is
   built into the compiler. Given the computational resources required
   to perform LLM inference, I do not expect AI review prompts to be
   integrated into any C compiler anytime soon.

Here are specific examples of what is possible with the Clang
thread-safety analysis and what falls outside the scope of any code
review software:
* Documenting which synchronization object protects which member
   variable (the __guarded_by() annotation). It can be very difficult
   or even ambiguous to derive from code which synchronization object is
   intended to protect which member variable. The Clang thread-safety
   support allows to annotate member variables with __guarded_by().
* Whether or not it is intentional that some code paths unlock a
   synchronization object and other paths do not. The Clang
   thread-safety annotations include __acquires() and __cond_acquires().
   These annotations not only enable compile time checking of
   synchronization calls but are also useful as documentation to humans.

Bart.