From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 1/2] btrfs: implement launder_folio for clearing dirty page rsv
Date: Tue, 23 Jul 2024 15:55:56 -0700 [thread overview]
Message-ID: <070b1d025ef6eb292638bb97683cd5c35ffe42eb.1721775142.git.boris@bur.io> (raw)
In-Reply-To: <cover.1721775142.git.boris@bur.io>
In the buffered write path, dirty pages can be said to "own" the qgroup
reservation until they create an ordered_extent. It is possible for
there to be outstanding dirty pages when a transaction is aborted, in
which case there is no cancellation path for freeing this reservation
and it is leaked.
We do already walk the list of outstanding delalloc inodes in
btrfs_destroy_delalloc_inodes and call invalidate_inode_pages2 on them.
This does *not* call btrfs_invalidate_folio, as one might guess, but
rather calls launder_folio and release_folio. Since this is a
reservation associated with dirty pages only, rather than something
associated with the private bit (ordered_extent is cancelled separately
already in the cleanup txn path), implementing this release should be
done via launder_folio.
Signed-off-by: Boris Burkov <boris@bur.io>
---
fs/btrfs/inode.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 8f38eefc8acd..c5155981f99a 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7198,6 +7198,11 @@ static void wait_subpage_spinlock(struct page *page)
spin_unlock_irq(&subpage->lock);
}
+static int btrfs_launder_folio(struct folio *folio)
+{
+ return btrfs_qgroup_free_data(folio_to_inode(folio), NULL, folio_pos(folio), PAGE_SIZE, NULL);
+}
+
static bool __btrfs_release_folio(struct folio *folio, gfp_t gfp_flags)
{
if (try_release_extent_mapping(&folio->page, gfp_flags)) {
@@ -10133,6 +10138,7 @@ static const struct address_space_operations btrfs_aops = {
.writepages = btrfs_writepages,
.readahead = btrfs_readahead,
.invalidate_folio = btrfs_invalidate_folio,
+ .launder_folio = btrfs_launder_folio,
.release_folio = btrfs_release_folio,
.migrate_folio = btrfs_migrate_folio,
.dirty_folio = filemap_dirty_folio,
--
2.45.2
next prev parent reply other threads:[~2024-07-23 22:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 22:55 [PATCH 0/2] btrfs: fixes for buffered write qgroup rsv leaks Boris Burkov
2024-07-23 22:55 ` Boris Burkov [this message]
2024-07-23 23:20 ` [PATCH 1/2] btrfs: implement launder_folio for clearing dirty page rsv Qu Wenruo
2024-07-23 22:55 ` [PATCH 2/2] btrfs: fix qgroup rsv leaks in cow_file_range Boris Burkov
2024-07-23 23:24 ` Qu Wenruo
2024-07-30 13:45 ` [PATCH 0/2] btrfs: fixes for buffered write qgroup rsv leaks David Sterba
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=070b1d025ef6eb292638bb97683cd5c35ffe42eb.1721775142.git.boris@bur.io \
--to=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.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