From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Baokun Li <libaokun1@huawei.com>,
linux-mm@kvack.org, linux-ext4@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, akpm@linux-foundation.org,
ritesh.list@gmail.com, linux-kernel@vger.kernel.org,
yi.zhang@huawei.com, yangerkun@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH -RFC 0/2] mm/ext4: avoid data corruption when extending DIO write race with buffered read
Date: Tue, 12 Dec 2023 04:36:45 +0000 [thread overview]
Message-ID: <ZXfjXZWK4HlJi6pg@casper.infradead.org> (raw)
In-Reply-To: <20231206193757.k5cppxqew6zjmbx3@quack3>
On Wed, Dec 06, 2023 at 08:37:57PM +0100, Jan Kara wrote:
> Within the same page buffered reads and writes should be consistent because
> they are synchronized by the page lock. However once reads and writes
> involve multiple pages, there is no serialization so you can get contents
> of some pages before write and some pages after being written. However this
> doesn't seem to be your particular case here. I just wanted to point out
> that in general even buffered reads vs writes are not fully consistent.
Buffered reads don't take the page/folio lock. We only use the folio
lock to avoid reading stale data from the page cache while we're
fetching the data from storage. Once the uptodate flag is set on the
folio, we never take the folio lock for reads.
next prev parent reply other threads:[~2023-12-12 4:37 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-02 9:14 [PATCH -RFC 0/2] mm/ext4: avoid data corruption when extending DIO write race with buffered read Baokun Li
2023-12-02 9:14 ` [PATCH -RFC 1/2] mm: " Baokun Li
2023-12-02 9:14 ` [PATCH -RFC 2/2] ext4: " Baokun Li
2023-12-04 12:11 ` [PATCH -RFC 0/2] mm/ext4: " Jan Kara
2023-12-04 13:50 ` Baokun Li
2023-12-04 14:41 ` Jan Kara
2023-12-05 12:50 ` Baokun Li
2023-12-06 19:37 ` Jan Kara
2023-12-07 3:01 ` Baokun Li
2023-12-07 14:15 ` Baokun Li
2023-12-11 17:49 ` Jan Kara
2023-12-12 2:15 ` Baokun Li
2023-12-12 4:36 ` Matthew Wilcox [this message]
2023-12-12 14:25 ` Jan Kara
2023-12-05 4:17 ` Theodore Ts'o
2023-12-05 13:19 ` Baokun Li
2023-12-06 21:55 ` Theodore Ts'o
2023-12-07 6:41 ` Baokun Li
2023-12-06 8:35 ` Dave Chinner
2023-12-06 9:02 ` Christoph Hellwig
2023-12-06 10:34 ` Dave Chinner
2023-12-06 12:20 ` Christoph Hellwig
2023-12-06 11:57 ` Baokun Li
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=ZXfjXZWK4HlJi6pg@casper.infradead.org \
--to=willy@infradead.org \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=jack@suse.cz \
--cc=libaokun1@huawei.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.com \
/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