From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: [PATCH v3 1/8] doc: Improve the description of __folio_mark_dirty
Date: Tue, 16 Apr 2024 04:17:45 +0100 [thread overview]
Message-ID: <20240416031754.4076917-2-willy@infradead.org> (raw)
In-Reply-To: <20240416031754.4076917-1-willy@infradead.org>
I've learned why it's safe to call __folio_mark_dirty() from
mark_buffer_dirty() without holding the folio lock, so update
the description to explain why.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
mm/page-writeback.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 62f28fe26511..bd91d5761e39 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2706,11 +2706,15 @@ void folio_account_cleaned(struct folio *folio, struct bdi_writeback *wb)
* If warn is true, then emit a warning if the folio is not uptodate and has
* not been truncated.
*
- * The caller must hold folio_memcg_lock(). Most callers have the folio
- * locked. A few have the folio blocked from truncation through other
- * means (eg zap_vma_pages() has it mapped and is holding the page table
- * lock). This can also be called from mark_buffer_dirty(), which I
- * cannot prove is always protected against truncate.
+ * The caller must hold folio_memcg_lock(). It is the caller's
+ * responsibility to prevent the folio from being truncated while
+ * this function is in progress, although it may have been truncated
+ * before this function is called. Most callers have the folio locked.
+ * A few have the folio blocked from truncation through other means (e.g.
+ * zap_vma_pages() has it mapped and is holding the page table lock).
+ * When called from mark_buffer_dirty(), the filesystem should hold a
+ * reference to the buffer_head that is being marked dirty, which causes
+ * try_to_free_buffers() to fail.
*/
void __folio_mark_dirty(struct folio *folio, struct address_space *mapping,
int warn)
--
2.43.0
next prev parent reply other threads:[~2024-04-16 3:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 3:17 [PATCH v3 0/8] Improve buffer head documentation Matthew Wilcox (Oracle)
2024-04-16 3:17 ` Matthew Wilcox (Oracle) [this message]
2024-04-16 3:17 ` [PATCH v3 2/8] buffer: Add kernel-doc for block_dirty_folio() Matthew Wilcox (Oracle)
2024-04-17 2:10 ` Randy Dunlap
2024-04-16 3:17 ` [PATCH v3 3/8] buffer: Add kernel-doc for try_to_free_buffers() Matthew Wilcox (Oracle)
2024-04-17 2:11 ` Randy Dunlap
2024-04-16 3:17 ` [PATCH v3 4/8] buffer: Fix __bread and __bread_gfp kernel-doc Matthew Wilcox (Oracle)
2024-04-17 2:12 ` Randy Dunlap
2024-04-16 3:17 ` [PATCH v3 5/8] buffer: Add kernel-doc for brelse() and __brelse() Matthew Wilcox (Oracle)
2024-04-17 2:13 ` Randy Dunlap
2024-04-16 3:17 ` [PATCH v3 6/8] buffer: Add kernel-doc for bforget() and __bforget() Matthew Wilcox (Oracle)
2024-04-17 2:13 ` Randy Dunlap
2024-04-16 3:17 ` [PATCH v3 7/8] buffer: Improve bdev_getblk documentation Matthew Wilcox (Oracle)
2024-04-16 3:17 ` [PATCH v3 8/8] doc: Split buffer.rst out of api-summary.rst Matthew Wilcox (Oracle)
2024-04-16 22:18 ` Randy Dunlap
2024-04-16 22:38 ` Randy Dunlap
2024-04-16 23:47 ` Matthew Wilcox
2024-04-17 1:57 ` [PATCH v3 8a/8] " Matthew Wilcox (Oracle)
2024-04-17 2:14 ` Randy Dunlap
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=20240416031754.4076917-2-willy@infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).