From: Dave Chinner <dgc@kernel.org>
To: Carlos Maiolino <cem@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, linux-xfs@vger.kernel.org
Subject: Re: improve log context annotations
Date: Wed, 22 Jul 2026 10:08:34 +1000 [thread overview]
Message-ID: <amAKAmIoTvoa6SY7@dread> (raw)
In-Reply-To: <al84nDC0BvHr33Kz@nidhogg.toxiclabs.cc>
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
dgc@kernel.org
next prev parent reply other threads:[~2026-07-22 0:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 9:45 improve log context annotations Christoph Hellwig
2026-07-20 9:45 ` [PATCH 1/8] xfs: fix the lock annotation on xfs_iget_cache_hit Christoph Hellwig
2026-07-20 9:45 ` [PATCH 2/8] xfs: fix the lock annotation in xfs_extent_busy_update_extent Christoph Hellwig
2026-07-20 9:45 ` [PATCH 3/8] xfs: fix the lock annotation in xfs_mru_cache_lookup Christoph Hellwig
2026-07-20 9:45 ` [PATCH 4/8] xfs: improve lock annotations in the log code Christoph Hellwig
2026-07-20 9:45 ` [PATCH 5/8] xfs: add lock annotations to xfs_try_open_zone Christoph Hellwig
2026-07-20 9:45 ` [PATCH 6/8] xfs: add lock annotations to xlog_state_shutdown_callbacks Christoph Hellwig
2026-07-20 9:45 ` [PATCH 7/8] xfs: add a lock annotation to xlog_cil_push_background Christoph Hellwig
2026-07-20 9:45 ` [PATCH 8/8] xfs: add lock annotations to xfs_ail_delete* Christoph Hellwig
2026-07-21 9:16 ` improve log context annotations Carlos Maiolino
2026-07-21 15:01 ` Christoph Hellwig
2026-07-21 15:23 ` Darrick J. Wong
2026-07-21 15:27 ` Christoph Hellwig
2026-07-22 0:08 ` Dave Chinner [this message]
2026-07-22 9:20 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amAKAmIoTvoa6SY7@dread \
--to=dgc@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox