From: Peter Zijlstra <peterz@infradead.org>
To: lizhe.67@bytedance.com
Cc: mingo@redhat.com, will@kernel.org, longman@redhat.com,
boqun.feng@gmail.com, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC 0/2] rwsem: introduce upgrade_read interface
Date: Wed, 16 Oct 2024 10:09:55 +0200 [thread overview]
Message-ID: <20241016080955.GR16066@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20241016043600.35139-1-lizhe.67@bytedance.com>
On Wed, Oct 16, 2024 at 12:35:58PM +0800, lizhe.67@bytedance.com wrote:
> From: Li Zhe <lizhe.67@bytedance.com>
>
> In the current kernel rwsem implementation, there is an interface to
> downgrade write lock to read lock, but there is no interface to upgrade
> a read lock to write lock. This means that in order to acquire write
> lock while holding read lock, we have to release the read lock first and
> then acquire the write lock, which will introduce some troubles in
> concurrent programming. This patch set provides the 'upgrade_read' interface
> to solve this problem. This interface can change a read lock to a write
> lock.
upgrade-read is fundamentally prone to deadlocks. Imagine two concurrent
invocations, each waiting for all readers to go away before proceeding
to upgrade to a writer.
Any solution to fixing that will end up being semantically similar to
dropping the read lock and acquiring a write lock -- there will not be a
single continuous critical section.
As such, this interface makes no sense.
next prev parent reply other threads:[~2024-10-16 8:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 4:35 lizhe.67
2024-10-16 4:35 ` [RFC 1/2] " lizhe.67
2024-10-16 4:56 ` Christoph Hellwig
2024-10-16 7:33 ` lizhe.67
2024-10-16 7:36 ` Christoph Hellwig
2024-10-16 8:00 ` lizhe.67
2024-10-16 8:03 ` Christoph Hellwig
2024-10-16 8:13 ` lizhe.67
2024-10-16 11:51 ` Matthew Wilcox
2024-10-16 12:21 ` Christoph Hellwig
2024-10-16 11:49 ` Matthew Wilcox
2024-10-17 6:23 ` lizhe.67
2024-10-16 14:23 ` Waiman Long
2024-10-16 18:05 ` Matthew Wilcox
2024-10-16 18:39 ` Waiman Long
2024-10-17 6:46 ` lizhe.67
2024-10-17 15:05 ` Christoph Hellwig
2024-10-17 17:36 ` Waiman Long
2024-10-18 5:06 ` Christoph Hellwig
2024-10-16 4:36 ` [RFC 2/2] khugepaged: use upgrade_read() to optimize collapse_huge_page lizhe.67
2024-10-16 11:53 ` Matthew Wilcox
2024-10-17 6:18 ` lizhe.67
2024-10-17 13:20 ` Matthew Wilcox
2024-10-18 6:37 ` lizhe.67
2024-10-23 7:27 ` kernel test robot
2024-10-16 8:09 ` Peter Zijlstra [this message]
2024-10-16 8:53 ` [RFC 0/2] rwsem: introduce upgrade_read interface lizhe.67
2024-10-16 12:10 ` Peter Zijlstra
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=20241016080955.GR16066@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=will@kernel.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