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]