[<prev] [next>] [day] [month] [year] [list]
Message-ID: <9bc50b26-d424-d48a-16db-6fd7e0e88f79@gmail.com>
Date: Wed, 3 Jul 2019 04:25:53 +0300
From: Boaz Harrosh <openosd@...il.com>
To: Patrick Farrell <pfarrell@...mcloud.com>,
Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.cz>
Cc: Amir Goldstein <amir73il@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Kent Overstreet <kent.overstreet@...il.com>,
Dave Chinner <dchinner@...hat.com>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Christoph Hellwig <hch@....de>,
Matthew Wilcox <willy@...radead.org>,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
linux-xfs <linux-xfs@...r.kernel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Josef Bacik <josef@...icpanda.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: pagecache locking
On 03/07/2019 04:07, Patrick Farrell wrote:
> Recursively read locking is generally unsafe, that’s why lockdep
> complains about it. The common RW lock primitives are queued in
> their implementation, meaning this recursive read lock sequence:
> P1 - read (gets lock)
> P2 - write
> P1 - read
>
> Results not in a successful read lock, but P1 blocking behind P2,
> which is blocked behind P1.
> Readers are not allowed to jump past waiting writers.
OK thanks that makes sense. I did not know about that last part. Its a kind
of a lock fairness I did not know we have.
So I guess I'll keep my two locks than. The write_locker is the SLOW
path for me anyway, right?
[if we are already at the subject, Do mutexes have the same lock fairness as
above? Do the write_lock side of rw_sem have same fairness? Something I never
figured out]
Thanks
Boaz
>
> - Patrick
Powered by blists - more mailing lists