On Mon, Sep 11, 2023 at 12:17:18AM +0100, Matthew Wilcox wrote:
On Mon, Sep 11, 2023 at 08:56:45AM +1000, Dave Chinner wrote:Sure, but that's no reason to stop anyone else from making progress.
On Fri, Sep 08, 2023 at 12:44:34PM +0200, Peter Zijlstra wrote:Some people are very creative ...
Agreed, and this is fine. However there's been some very creativeSo your argument against such an interface is essentially "we can't
'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.
have nice things because someone might abuse them"?
I was thinking about how to handle this better. We could haveWe already have CONFIG_DEBUG_RWSEMS, so we can put these
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);
}
introspection interfaces inside debug code, and make any attempt to
use them outside of debug builds break the build. e.g:
#if DEBUG_RWSEMS
/*
* rwsem locked checks can only be used by conditionally compiled
* subsystem debug code. It is not valid to use them in normal
* production code.
*/
static inline bool rwsem_is_write_locked()
{
....
}
static inline bool rwsem_is_locked()
{
....
}
#else /* !DEBUG_RWSEMS */
#define rwsem_is_write_locked() BUILD_BUG()
#define rwsem_is_locked() BUILD_BUG()
#endif /* DEBUG_RWSEMS */
And now we simply add a single line to subsystem Kconfig debug
options to turn on rwsem introspection for their debug checks like
so:
config XFS_DEBUG
bool "XFS Debugging support"
depends on XFS_FS
+ select RWSEM_DEBUG
help
Say Y here to get an XFS build with many debugging features,
including ASSERT checks, function wrappers around macros,