RFC: asserting an inode is locked

[Matthew Wilcox <willy@infradead.org>]

I have this patch in my tree that I'm thinking about submitting:

+static inline void inode_assert_locked(const struct inode *inode)
+{
+       rwsem_assert_held(&inode->i_rwsem);
+}
+
+static inline void inode_assert_locked_excl(const struct inode *inode)
+{
+       rwsem_assert_held_write(&inode->i_rwsem);
+}

Then we can do a whole bunch of "replace crappy existing assertions with
the shiny new ones".

@@ -2746,7 +2746,7 @@ struct dentry *lookup_one_len(const char *name, struct den
try *base, int len)
        struct qstr this;
        int err;

-       WARN_ON_ONCE(!inode_is_locked(base->d_inode));
+       inode_assert_locked(base->d_inode);

for example.

But the naming is confusing and I can't think of good names.

inode_lock() takes the lock exclusively, whereas inode_assert_locked()
only checks that the lock is held.  ie 1-3 pass and 4 fails.

1.	inode_lock(inode);		inode_assert_locked(inode);
2.	inode_lock_shared(inode);	inode_assert_locked(inode);
3.	inode_lock(inode);		inode_assert_locked_excl(inode);
4.	inode_lock_shared(inode);	inode_assert_locked_excl(inode);

I worry that this abstraction will cause people to write
inode_assert_locked() when they really need to check
inode_assert_locked_excl().  We already had/have this problem:
https://lore.kernel.org/all/20230831101824.qdko4daizgh7phav@f/

So how do we make it that people write the right one?
Renaming inode_assert_locked() to inode_assert_locked_shared() isn't
the answer because it checks that the lock is _at least_ shared, it
might be held exclusively.

Rename inode_assert_locked() to inode_assert_held()?  That might be
enough of a disconnect that people would not make bad assumptions.
I don't have a good answer here, or I'd send a patch to do that.
Please suggest something ;-)