From: Waiman Long <longman@redhat.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J . Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, Mateusz Guzik <mjguzik@gmail.com>
Subject: Re: [PATCH v3 1/4] locking: Add rwsem_assert_held() and rwsem_assert_held_write()
Date: Tue, 14 Nov 2023 20:17:32 -0500 [thread overview]
Message-ID: <72dced0f-6d49-4522-beeb-1a398d8f2557@redhat.com> (raw)
In-Reply-To: <ZVPmCoLVXyShSrkN@casper.infradead.org>
On 11/14/23 16:26, Matthew Wilcox wrote:
> On Fri, Nov 10, 2023 at 05:21:22PM -0500, Waiman Long wrote:
>> On 11/10/23 15:41, Matthew Wilcox (Oracle) wrote:
>>> static inline int rwsem_is_locked(struct rw_semaphore *sem)
>>> {
>>> - return atomic_long_read(&sem->count) != 0;
>>> + return atomic_long_read(&sem->count) != RWSEM_UNLOCKED_VALUE;
>>> }
>>> -#define RWSEM_UNLOCKED_VALUE 0L
>>> -#define __RWSEM_COUNT_INIT(name) .count = ATOMIC_LONG_INIT(RWSEM_UNLOCKED_VALUE)
>>> +static inline void rwsem_assert_held_nolockdep(const struct rw_semaphore *sem)
>>> +{
>>> + WARN_ON(atomic_long_read(&sem->count) == RWSEM_UNLOCKED_VALUE);
>>> +}
>> That is not correct. You mean "!= RWSEM_UNLOCKED_VALUE". Right?
> Uhhh ... I always get confused between assert and BUG_ON being opposite
> polarity, but I think it's correct.
>
> We are asserting that the rwsem is locked (either for read or write).
> That is, it is a bug if the rwsem is unlocked.
> So WARN_ON(sem->count == UNLOCKED_VALUE) is correct. No?
You are right. I got confused too.
>
>> There are some inconsistency in the use of WARN_ON() and BUG_ON() in the
>> assertions. For PREEMPT_RT, held_write is a BUG_ON. For non-PREEMPT_RT, held
>> is a BUG_ON. It is not clear why one is BUG_ON and other one is WARN_ON. Is
>> there a rationale for that?
> I'll fix that up.
The check for write lock ownership is accurate. OTOH, the locked check
can have false positive and so is less reliable.
>
>> BTW, we can actually check if the current process is the write-lock owner of
>> a rwsem, but not for a reader-owned rwsem.
> We actually don't want to do that. See patches 3/4 where I explain how
> XFS takes the XFS_ILOCK for write, then passes control to a workqueue
> which asserts that the XFS_ILOCK is held for write. The thread which
> took the rwsem for write waits for the workqueue and unlocks the rwsem.
>
I see. Thanks for the explanation.
Cheers,
Longman
next prev parent reply other threads:[~2023-11-15 1:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 20:41 [PATCH v3 0/4] Remove the XFS mrlock Matthew Wilcox (Oracle)
2023-11-10 20:41 ` [PATCH v3 1/4] locking: Add rwsem_assert_held() and rwsem_assert_held_write() Matthew Wilcox (Oracle)
2023-11-10 22:21 ` Waiman Long
2023-11-14 21:26 ` Matthew Wilcox
2023-11-15 1:17 ` Waiman Long [this message]
2023-11-16 16:12 ` Matthew Wilcox
2023-11-17 1:50 ` Waiman Long
2023-11-13 8:24 ` Peter Zijlstra
2023-11-10 20:41 ` [PATCH v3 2/4] mm: Use rwsem assertion macros for mmap_lock Matthew Wilcox (Oracle)
2023-11-10 20:41 ` [PATCH v3 3/4] xfs: Replace xfs_isilocked with xfs_assert_ilocked Matthew Wilcox (Oracle)
2023-11-10 20:41 ` [PATCH v3 4/4] xfs: Remove mrlock wrapper Matthew Wilcox (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72dced0f-6d49-4522-beeb-1a398d8f2557@redhat.com \
--to=longman@redhat.com \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjguzik@gmail.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox