From: Jan Kara <jack@suse.cz>
To: Ted Tso <tytso@mit.edu>
Cc: <linux-ext4@vger.kernel.org>, Jan Kara <jack@suse.cz>
Subject: [PATCH 3/7] ext4: Mark page for delayed dirtying only if it is pinned
Date: Wed, 11 Jan 2023 16:43:27 +0100 [thread overview]
Message-ID: <20230111154338.392-3-jack@suse.cz> (raw)
In-Reply-To: <20230111152736.9608-1-jack@suse.cz>
In data=journal mode, page should be dirtied only when it has buffers
for checkpoint or it is writeably mapped. In the first case, we don't
need to do anything special. In the second case, page was already added
to the journal by ext4_page_mkwrite() and since transaction commit
writeprotects mapped pages again, page should be writeable (and thus
dirtied) only while it is part of the running transaction. So nothing
needs to be done either. The only special case is when someone pins the
page and uses this pin for modifying page data. So recognize this
special case and only then mark the page as having data that needs
adding to the journal.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext4/inode.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 13cab2a47f99..4c14aa1b9152 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3670,24 +3670,26 @@ const struct iomap_ops ext4_iomap_report_ops = {
};
/*
- * Whenever the folio is being dirtied, corresponding buffers should already
- * be attached to the transaction (we take care of this in ext4_page_mkwrite()
- * and ext4_write_begin()). However we cannot move buffers to dirty transaction
- * lists here because ->dirty_folio is called under VFS locks and the folio
- * is not necessarily locked.
- *
- * We cannot just dirty the folio and leave attached buffers clean, because the
- * buffers' dirty state is "definitive". We cannot just set the buffers dirty
- * or jbddirty because all the journalling code will explode.
- *
- * So what we do is to mark the folio "pending dirty" and next time writepage
- * is called, propagate that into the buffers appropriately.
+ * For data=journal mode, folio should be marked dirty only when it was
+ * writeably mapped. When that happens, it was already attached to the
+ * transaction and marked as jbddirty (we take care of this in
+ * ext4_page_mkwrite()). On transaction commit, we writeprotect page mappings
+ * so we should have nothing to do here, except for the case when someone
+ * had the page pinned and dirtied the page through this pin (e.g. by doing
+ * direct IO to it). In that case we'd need to attach buffers here to the
+ * transaction but we cannot due to lock ordering. We cannot just dirty the
+ * folio and leave attached buffers clean, because the buffers' dirty state is
+ * "definitive". We cannot just set the buffers dirty or jbddirty because all
+ * the journalling code will explode. So what we do is to mark the folio
+ * "pending dirty" and next time ext4_writepages() is called, attach buffers
+ * to the transaction appropriately.
*/
static bool ext4_journalled_dirty_folio(struct address_space *mapping,
struct folio *folio)
{
WARN_ON_ONCE(!folio_buffers(folio));
- folio_set_checked(folio);
+ if (folio_may_be_dma_pinned(folio))
+ folio_set_checked(folio);
return filemap_dirty_folio(mapping, folio);
}
--
2.35.3
next prev parent reply other threads:[~2023-01-11 15:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-11 15:43 [PATCH 0/7] ext4: Cleanup data=journal writeback path Jan Kara
2023-01-11 15:43 ` [PATCH 1/7] ext4: Update stale comment about write constraints Jan Kara
2023-01-11 15:43 ` [PATCH 2/7] ext4: Use nr_to_write directly in mpage_prepare_extent_to_map() Jan Kara
2023-01-11 15:43 ` Jan Kara [this message]
2023-01-11 22:34 ` [PATCH 3/7] ext4: Mark page for delayed dirtying only if it is pinned kernel test robot
2023-01-12 1:36 ` kernel test robot
2023-01-12 2:07 ` kernel test robot
2023-01-12 9:29 ` Jan Kara
2023-01-11 15:43 ` [PATCH 4/7] ext4: Don't unlock page in ext4_bio_write_page() Jan Kara
2023-01-11 15:43 ` [PATCH 5/7] ext4: Move page unlocking out of mpage_submit_page() Jan Kara
2023-01-11 15:43 ` [PATCH 6/7] ext4: Move mpage_page_done() calls after error handling Jan Kara
2023-01-11 15:43 ` [PATCH 7/7] ext4: Convert data=journal writeback to use ext4_writepages() Jan Kara
2023-02-19 5:40 ` [PATCH 0/7] ext4: Cleanup data=journal writeback path Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2023-02-28 5:13 [PATCH REBASED " Theodore Ts'o
2023-02-28 5:13 ` [PATCH 3/7] ext4: Mark page for delayed dirtying only if it is pinned Theodore Ts'o
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=20230111154338.392-3-jack@suse.cz \
--to=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.