From: Christoph Hellwig <hch@infradead.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Keith Busch <kbusch@meta.com>,
linux-block@vger.kernel.org, axboe@kernel.dk,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Anuj Gupta <anuj20.g@samsung.com>
Subject: Re: [PATCH] block: integrity: Do not call set_page_dirty_lock()
Date: Mon, 21 Apr 2025 05:06:16 -0700 [thread overview]
Message-ID: <aAY0uKkZF254PYLE@infradead.org> (raw)
In-Reply-To: <aAER-5JH38mYNMiu@casper.infradead.org>
On Thu, Apr 17, 2025 at 03:36:43PM +0100, Matthew Wilcox wrote:
> Let's suppose we're allocating the PI buffer in anonymous memory.
> Also, we're under memory pressure. We've already swapped out the page
> containing the PI buffer once, so it's in the swap cache and marked
> as clean. We do a READ from the device, and the new metadata is written
> to the page. Then a new round of memory reclaim happens and this page
> is chosen. If it's still clean, the new contents will not be written
> to swap and the page will simply be discarded. When we go to validate
> the PI data, the page will be swapped back in, but it will have old PI
> information in it so the verification will fail.
>
> What we need to do is mark the folio dirty at pin time. I believe
> O_DIRECT does this properly, and I'm not sure whether this code does it
> properly or not.
O_DIRECT reads dirty right after pinning and then check if the dirty
bit has been cleared in the I/O completion handler and redirty from a
workqueue if so. We're currently trying to figure out if we still need
that redirtying with proper pinning.
Either way metadata should follow the data behavior 1:1 here and
preferably also share the code for that as much as possible.
prev parent reply other threads:[~2025-04-21 12:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-16 20:04 [PATCH] block: integrity: Do not call set_page_dirty_lock() Martin K. Petersen
2025-04-16 20:15 ` Keith Busch
2025-04-16 22:01 ` Martin K. Petersen
2025-04-16 20:17 ` Jens Axboe
2025-04-17 6:16 ` Christoph Hellwig
2025-04-17 14:05 ` Martin K. Petersen
2025-04-21 5:12 ` Christoph Hellwig
2025-04-22 2:14 ` Martin K. Petersen
2025-04-22 6:13 ` Christoph Hellwig
2025-04-17 14:36 ` Matthew Wilcox
2025-04-21 12:06 ` Christoph Hellwig [this message]
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=aAY0uKkZF254PYLE@infradead.org \
--to=hch@infradead.org \
--cc=Liam.Howlett@oracle.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=kbusch@meta.com \
--cc=linux-block@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.