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
Subject: Re: [PATCH 1/5] locking: Add rwsem_is_write_locked()
Date: Thu, 7 Sep 2023 19:47:31 -0400 [thread overview]
Message-ID: <c38847cb-92c9-139f-03cc-86d233297d58@redhat.com> (raw)
In-Reply-To: <da1daacf-22b2-20da-b6c0-9b1362b8a901@redhat.com>
On 9/7/23 17:06, Waiman Long wrote:
>
> On 9/7/23 15:33, Matthew Wilcox wrote:
>> On Thu, Sep 07, 2023 at 02:05:54PM -0400, Waiman Long wrote:
>>> On 9/7/23 13:47, Matthew Wilcox (Oracle) wrote:
>>>> +static inline int rwsem_is_write_locked(struct rw_semaphore *sem)
>>>> +{
>>>> + return atomic_long_read(&sem->count) & 1 /*
>>>> RWSEM_WRITER_LOCKED */;
>>>> +}
>>> I would prefer you move the various RWSEM_* count bit macros from
>>> kernel/locking/rwsem.c to under the !PREEMPT_RT block and directly use
>>> RWSEM_WRITER_LOCKED instead of hardcoding a value of 1.
>> Just to be clear, you want the ~50 lines from:
>>
>> /*
>> * On 64-bit architectures, the bit definitions of the count are:
>> ...
>> #define RWSEM_READ_FAILED_MASK (RWSEM_WRITER_MASK|RWSEM_FLAG_WAITERS|\
>> RWSEM_FLAG_HANDOFF|RWSEM_FLAG_READFAIL)
>>
>> moved from rwsem.c to rwsem.h?
>>
>> Or just these four lines:
>>
>> #define RWSEM_WRITER_LOCKED (1UL << 0)
>> #define RWSEM_FLAG_WAITERS (1UL << 1)
>> #define RWSEM_FLAG_HANDOFF (1UL << 2)
>> #define RWSEM_FLAG_READFAIL (1UL << (BITS_PER_LONG - 1))
>
> I think just the first 3 lines will be enough. Maybe a bit of comment
> about these bit flags in the count atomic_long value.
Actually, the old rwsem implementation won't allow you to reliably
determine if a rwsem is write locked because the xadd instruction is
used for write locking and the code had to back out the WRITER_BIAS if
the attempt failed. Maybe that is why XFS has its own code to check if a
rwsem is write locked which is needed with the old rwsem implementation.
The new implementation makes this check reliable. Still it is not easy
to check if a rwsem is read locked as the check will be rather
complicated and probably racy.
Cheers,
Longman
next prev parent reply other threads:[~2023-09-07 23:47 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 17:47 [PATCH 0/5] Remove the XFS mrlock Matthew Wilcox (Oracle)
2023-09-07 17:47 ` [PATCH 1/5] locking: Add rwsem_is_write_locked() Matthew Wilcox (Oracle)
2023-09-07 18:05 ` Waiman Long
2023-09-07 19:33 ` Matthew Wilcox
2023-09-07 21:06 ` Waiman Long
2023-09-07 23:47 ` Waiman Long [this message]
2023-09-08 0:44 ` Dave Chinner
2023-09-07 19:08 ` Peter Zijlstra
2023-09-07 19:20 ` Matthew Wilcox
2023-09-07 19:38 ` Peter Zijlstra
2023-09-07 23:00 ` Dave Chinner
2023-09-08 10:44 ` Peter Zijlstra
2023-09-10 22:56 ` Dave Chinner
2023-09-10 23:17 ` Matthew Wilcox
2023-09-11 0:55 ` Dave Chinner
2023-09-11 2:15 ` Waiman Long
2023-09-11 22:29 ` Dave Chinner
2023-09-12 9:03 ` Peter Zijlstra
2023-09-12 12:28 ` Matthew Wilcox
2023-09-12 13:52 ` Peter Zijlstra
2023-09-12 13:58 ` Matthew Wilcox
2023-09-12 14:23 ` Peter Zijlstra
2023-09-12 15:27 ` Darrick J. Wong
2023-09-13 8:59 ` Peter Zijlstra
2023-09-12 14:02 ` Peter Zijlstra
2023-09-12 23:16 ` Dave Chinner
2023-09-08 0:01 ` Matthew Wilcox
2023-09-07 17:47 ` [PATCH 2/5] mm: Use rwsem_is_write_locked in mmap_assert_write_locked Matthew Wilcox (Oracle)
2023-09-07 17:47 ` [PATCH 3/5] xfs: Use rwsem_is_write_locked() Matthew Wilcox (Oracle)
2023-09-08 9:09 ` Christoph Hellwig
2023-09-08 9:10 ` Christoph Hellwig
2023-09-07 17:47 ` [PATCH 4/5] xfs: Remove mrlock wrapper Matthew Wilcox (Oracle)
2023-09-07 17:47 ` [PATCH 5/5] xfs: Stop using lockdep to assert that locks are held 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=c38847cb-92c9-139f-03cc-86d233297d58@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=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