On Mon, Sep 11, 2023 at 08:56:45AM +1000, Dave Chinner wrote:
> On Fri, Sep 08, 2023 at 12:44:34PM +0200, Peter Zijlstra wrote:
> > Agreed, and this is fine. However there's been some very creative
> > 'use' of the _is_locked() class of functions in the past that did not
> > follow 'common' sense.
> >
> > If all usage was: I should be holding this, lets check. I probably
> > wouldn't have this bad feeling about things.
>
> So your argument against such an interface is essentially "we can't
> have nice things because someone might abuse them"?
Some people are very creative ...
I was thinking about how to handle this better. We could have
static inline void rwsem_assert_locked(const struct rw_semaphore *sem)
{
BUG_ON(atomic_long_read(&sem->count) == 0);
}
static inline void rwsem_assert_write_locked(const struct rw_semaphore *sem)
{
BUG_ON((atomic_long_read(&sem->count) & 1) != 1);
}
but then we'd also need to change how XFS currently uses the ASSERT()
macro to be ASSERT_LOCKED(ip, flags), and I understand this code is also
used in userspace, so it'd involve changing that shim, and we're getting
way past the amount of code I'm comfortable changing, and way past the
amount of time I should be spending on this.
And then there'd be the inevitable bikeshedding about "don't use BUG_ON"
and it's probably just for the best if I walk away at this point,
becoming the third person to fail to remove the mrlock.
I'll keep reading this thread to see if some consensus emerges, but I'm
not optimistic.
