[PATCH] mm/page-writeback: document folio_mark_dirty() locking more explicitly

I have found two out-of-tree driver bugs in the past where set_page_dirty()
was used on a page from GUP without appropriate locking, leading to UAF:

 - https://project-zero.issues.chromium.org/42450908 (in Qualcomm's Adreno
   GPU driver)
 - https://project-zero.issues.chromium.org/494546491 (in Google Pixel's
   GXP driver)

Today I found another instance of this in mainline:
https://lore.kernel.org/r/[email protected]

I think this shows that set_page_dirty() and folio_mark_dirty() at least
need more explicit documentation; so add a comment on top of
set_page_dirty() and make the comment above folio_mark_dirty() more
explicit.

Signed-off-by: Jann Horn <[email protected]>
---
 mm/folio-compat.c   | 1 +
 mm/page-writeback.c | 5 +++++
 2 files changed, 6 insertions(+)

diff --git a/mm/folio-compat.c b/mm/folio-compat.c
index a02179a0bded..6212fdd6761a 100644
--- a/mm/folio-compat.c
+++ b/mm/folio-compat.c
@@ -41,6 +41,7 @@ void set_page_writeback(struct page *page)
 }
 EXPORT_SYMBOL(set_page_writeback);
 
+/* Read the comment above folio_mark_dirty() regarding required locks! */
 bool set_page_dirty(struct page *page)
 {
 	return folio_mark_dirty(page_folio(page));
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index e98748112d1e..b0ab687c83be 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2773,6 +2773,11 @@ EXPORT_SYMBOL(folio_redirty_for_writepage);
  * in this folio.  Truncation will block on the page table lock as it
  * unmaps pages before removing the folio from its mapping.
  *
+ * .. DANGER::
+ *    Do not use this on a folio obtained from a function like
+ *    get_user_pages_fast() without holding appropriate locks; you might want to
+ *    use set_page_dirty_lock() or folio_mark_dirty_lock() instead.
+ *
  * Return: True if the folio was newly dirtied, false if it was already dirty.
  */
 bool folio_mark_dirty(struct folio *folio)

---
base-commit: db2ddb87143519e20a95aa36c60b36107b736a58
change-id: 20260810-set-page-dirty-warnings-4000f0015394

Best regards,
--  
Jann Horn <[email protected]>