All of lore.kernel.org
 help / color / mirror / Atom feed
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

      parent reply	other threads:[~2026-07-22  0:08 UTC|newest]

Thread overview: 14+ 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]

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.