[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230912152715.GS28202@frogsfrogsfrogs>
Date: Tue, 12 Sep 2023 08:27:15 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Matthew Wilcox <willy@...radead.org>,
Dave Chinner <david@...morbit.com>,
Waiman Long <longman@...hat.com>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Chandan Babu R <chandan.babu@...cle.com>,
linux-xfs@...r.kernel.org
Subject: Re: [PATCH 1/5] locking: Add rwsem_is_write_locked()
On Tue, Sep 12, 2023 at 04:23:00PM +0200, Peter Zijlstra wrote:
> On Tue, Sep 12, 2023 at 02:58:32PM +0100, Matthew Wilcox wrote:
> > On Tue, Sep 12, 2023 at 03:52:13PM +0200, Peter Zijlstra wrote:
> > > On Tue, Sep 12, 2023 at 01:28:13PM +0100, Matthew Wilcox wrote:
> > > > On Tue, Sep 12, 2023 at 11:03:42AM +0200, Peter Zijlstra wrote:
> > > > > If not, then sure we can do this; it's not like I managed to get rid of
> > > > > muteX_is_locked() -- and I actually tried at some point :/
> > > > >
> > > > > And just now I grepped for it, and look what I find:
> > > > >
> > > > > drivers/hid/hid-nintendo.c: if (unlikely(mutex_is_locked(&ctlr->output_mutex))) {
> > > > > drivers/nvdimm/btt.c: if (mutex_is_locked(&arena->err_lock)
> > > > >
> > > > > And there's more :-(
> > > >
> > > > Are these actually abuse? I looked at these two, and they both seem to
> > > > be asking "Does somebody else currently have this mutex?" rather than
> > > > "Do I have this mutex?".
> > >
> > > It's effectively a random number generator in that capacity. Someone
> > > might have it or might have had it when you looked and no longer have
> > > it, or might have it now but not when you asked.
> >
> > Well, no.
> >
> > if (mutex_is_locked(&arena->err_lock)
> > || arena->freelist[lane].has_err) {
> > nd_region_release_lane(btt->nd_region, lane);
> >
> > ret = arena_clear_freelist_error(arena, lane);
> >
> > So that's "Is somebody currently processing an error, or have they
> > already finished setting an error". Sure, it's somewhat racy, but
> > it looks like a performance optimisation, not something that needs
> > 100% accuracy.
>
> We're arguing past one another I think. Yes mutex_is_locked() is a
> random number generator when asked for something you don't own. But it
> might not be a bug because the code is ok with races.
>
> It is still fully dodgy IMO, such usage is pretty close to UB.
My 2 cents here:
I could live with Longman's suggestion of an rwsem_assert_is_locked that
only exists if DEBUG_RWSEMS is enabled. Something like:
#ifdef CONFIG_DEBUG_RWSEMS
static inline bool __rwsem_assert_is_locked(struct rw_semaphore *rwsem,
const char *file, int line)
{
bool ret = rwsem_is_locked(rwsem);
if (!ret)
WARN(1, "!rwsem_is_locked(rwsem) at %s line %d", file, line);
return ret;
}
#define rwsem_assert_is_locked(r) \
__rwsem_assert_is_locked((r), __FILE__, __LINE__)
#endif
and then XFS could do:
ASSERT(rwsem_assert_is_locked(&VFS_I(ip)->i_rwsem));
Wherein ASSERT is only #defined if CONFIG_XFS_DEBUG, and XFS_DEBUG
selects DEBUG_RWSEMS, per Longman's suggestion. That's work for what we
want it for (simple cheap lock checking) without becoming a general
lockabuse predicate.
--D
Powered by blists - more mailing lists