Re: [PATCH 1/5] locking: Add rwsem_is_write_locked()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 9/10/23 20:55, Dave Chinner wrote:
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:
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 ...
Sure, but that's no reason to stop anyone else from making progress.

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);
We already have CONFIG_DEBUG_RWSEMS, so we can put these
introspection interfaces inside debug code, and make any attempt to
use them outside of debug builds break the build. e.g:

  * 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

  config XFS_DEBUG
  	bool "XFS Debugging support"
  	depends on XFS_FS
+	select RWSEM_DEBUG
  	  Say Y here to get an XFS build with many debugging features,
  	  including ASSERT checks, function wrappers around macros,

That may be a possible compromise. Actually, I am not against having them defined even outside the DEBUG_RWSEMS. We already have mutex_is_locked() defined and used in a lot of places. So this is just providing the rwsem equivalents.

I also agreed that these APIs can be misused by other users. I think we should clearly document the caveats of using these. So unless there are other means of maintaining the stability of the lock state, the test result may no longer be true right after the test. It is simply just the lock state at a certain moment in time. Callers are using them at their own risk.


[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]

  Powered by Linux