Re: improve log context annotations

Dave Chinner <[email protected]>
Newsgroups org.kernel.vger.linux-xfs
Message-ID <amAKAmIoTvoa6SY7@dread>
On Tue, Jul 21, 2026 at 11:16:40AM +0200, Carlos Maiolino wrote:
> On Mon, Jul 20, 2026 at 11:45:37AM +0200, Christoph Hellwig wrote:
> > Hi Carlos,
> > 
> > this series improves the lock annotations in the XFS code.
> > 
> > Note that right now this is all mostly unused - the less stringent sparse
> > lock context checks got disabled when the clang version was merged, and
> > we're not quite ready to enable the latter yet due to our conditional
> > locking in the ilock helper and the locking contexts transferred to the
> > transaction for the inode and dquot locks, but I'm working on that.
> > 
> > In the meantime having these corrected at least serves as useful
> > documentation.
> 
> Thanks. Those all look good for me. But I'm adding Dave to the thread as
> he has much more expertise with lockdep than me and I'd appreciate his
> input.

Honestly, I'd prefer to kill the annotations and replace them with
asserts that the lock is held so there's actual runtime validation
that catches errors when they occur. These lock annotations don't
tell you that the locking is correct, just that the function
manipulates a lock.

The sparse annotations have always been more of an annoyance and
reactive, because we only use them sporadically to suppress errors.
We do not use them to prove locking is actually correct, nor can
they function as such.  i.e. They exist purely to shut up a set of
"not smart enough to understand lock context" tooling failures from
a tool that almost nobody ever ran.

Maybe the clang checker will be better, but I still don't see how it
will ever be able to provide any sort of "locking is correct" proof,
nor that it will be something everyone always runs.

Hence this just seems like trying to maintain a technical debt that
doesn't really serve any useful purpose anymore.

-Dave.
-- 
Dave Chinner
[email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.