From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Tal Zussman <tz2294@columbia.edu>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Zi Yan <ziy@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Hugh Dickins <hughd@google.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] mm: remove clear_page_dirty_for_io()
Date: Tue, 3 Nov 2026 08:34:15 +0000 [thread overview]
Message-ID: <aumcgdzoPhuB6zQc@gremlin> (raw)
In-Reply-To: <20261102-page-wrappers-v1-3-e7280bdb31f6@columbia.edu>
On Mon, Nov 02, 2026 at 05:54:08PM -0500, Tal Zussman wrote:
> There are no callers left. Point the comments that named it at
> folio_clear_dirty_for_io() instead.
>
> Signed-off-by: Tal Zussman <tz2294@columbia.edu>
LGTM!
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> include/linux/pagemap.h | 1 -
> mm/folio-compat.c | 6 ------
> mm/gup.c | 6 +++---
> mm/page-writeback.c | 2 +-
> 4 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 692ce3867a1d..9adfeae2153c 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -1315,7 +1315,6 @@ static inline void folio_cancel_dirty(struct folio *folio)
> __folio_cancel_dirty(folio);
> }
> bool folio_clear_dirty_for_io(struct folio *folio);
> -bool clear_page_dirty_for_io(struct page *page);
> void folio_invalidate(struct folio *folio, size_t offset, size_t length);
> bool noop_dirty_folio(struct address_space *mapping, struct folio *folio);
>
> diff --git a/mm/folio-compat.c b/mm/folio-compat.c
> index 9f2cd0ebfbbd..13d4d39e1896 100644
> --- a/mm/folio-compat.c
> +++ b/mm/folio-compat.c
> @@ -42,12 +42,6 @@ int set_page_dirty_lock(struct page *page)
> }
> EXPORT_SYMBOL(set_page_dirty_lock);
>
> -bool clear_page_dirty_for_io(struct page *page)
> -{
> - return folio_clear_dirty_for_io(page_folio(page));
> -}
> -EXPORT_SYMBOL(clear_page_dirty_for_io);
> -
> bool redirty_page_for_writepage(struct writeback_control *wbc,
> struct page *page)
> {
> diff --git a/mm/gup.c b/mm/gup.c
> index 7d43ce717b24..335dcb3a5c17 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -298,16 +298,16 @@ void unpin_user_pages_dirty_lock(struct page **pages, unsigned long npages,
> folio = gup_folio_next(pages, npages, i, &nr);
> /*
> * Checking PageDirty at this point may race with
> - * clear_page_dirty_for_io(), but that's OK. Two key
> + * folio_clear_dirty_for_io(), but that's OK. Two key
> * cases:
> *
> * 1) This code sees the page as already dirty, so it
> * skips the call to set_page_dirty(). That could happen
> - * because clear_page_dirty_for_io() called
> + * because folio_clear_dirty_for_io() called
> * folio_mkclean(), followed by set_page_dirty().
> * However, now the page is going to get written back,
> * which meets the original intention of setting it
> - * dirty, so all is well: clear_page_dirty_for_io() goes
> + * dirty, so all is well: folio_clear_dirty_for_io() goes
> * on to call TestClearPageDirty(), and write the page
> * back.
> *
> diff --git a/mm/page-writeback.c b/mm/page-writeback.c
> index 0694ec4098f6..b56f2c91b0f2 100644
> --- a/mm/page-writeback.c
> +++ b/mm/page-writeback.c
> @@ -2821,7 +2821,7 @@ EXPORT_SYMBOL(folio_mark_dirty_lock);
> * This cancels just the dirty bit on the kernel page itself, it does NOT
> * actually remove dirty bits on any mmap's that may be around. It also
> * leaves the page tagged dirty, so any sync activity will still find it on
> - * the dirty lists, and in particular, clear_page_dirty_for_io() will still
> + * the dirty lists, and in particular, folio_clear_dirty_for_io() will still
> * look at the dirty bits in the VM.
> *
> * Doing this should *normally* only ever be done when a page is truncated,
>
> --
> 2.39.5
>
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-11-03 8:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 22:54 [PATCH 0/8] mm: remove newly-unused page wrapper APIs Tal Zussman
2026-11-02 22:54 ` [PATCH 1/8] mm: remove wait_on_page_writeback() Tal Zussman
2026-11-03 1:34 ` SJ Park
2026-11-03 3:42 ` Zi Yan
2026-11-03 8:32 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 2/8] mm: remove end_page_writeback() Tal Zussman
2026-11-03 1:36 ` SJ Park
2026-11-03 3:43 ` Zi Yan
2026-11-03 8:33 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 3/8] mm: remove clear_page_dirty_for_io() Tal Zussman
2026-11-03 1:39 ` SJ Park
2026-11-03 3:44 ` Zi Yan
2026-11-03 8:34 ` Lorenzo Stoakes (ARM) [this message]
2026-11-02 22:54 ` [PATCH 4/8] mm: remove attach_page_private() and detach_page_private() Tal Zussman
2026-11-03 1:40 ` SJ Park
2026-11-03 3:44 ` Zi Yan
2026-11-03 8:34 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 5/8] mm: remove find_get_page_flags() Tal Zussman
2026-11-03 1:41 ` SJ Park
2026-11-03 3:45 ` Zi Yan
2026-11-03 8:35 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 6/8] mm: remove find_lock_page() Tal Zussman
2026-11-03 1:43 ` SJ Park
2026-11-03 3:46 ` Zi Yan
2026-11-03 8:36 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 7/8] mm: remove read_cache_page_gfp() Tal Zussman
2026-11-03 1:45 ` SJ Park
2026-11-03 3:46 ` Zi Yan
2026-11-03 8:37 ` Lorenzo Stoakes (ARM)
2026-11-02 22:54 ` [PATCH 8/8] mm: remove thp_size() and thp_order() Tal Zussman
2026-11-03 1:48 ` SJ Park
2026-11-03 3:47 ` Zi Yan
2026-11-03 8:42 ` Lorenzo Stoakes (ARM)
2026-11-03 1:56 ` [PATCH 0/8] mm: remove newly-unused page wrapper APIs Andrew Morton
2026-11-03 8:45 ` David Hildenbrand (Arm)
2026-11-03 9:02 ` Christoph Hellwig
2026-11-03 9:29 ` Vishal Moola (Fractile)
2026-11-03 9:14 ` Vishal Moola (Fractile)
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=aumcgdzoPhuB6zQc@gremlin \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joshua.hahnjy@gmail.com \
--cc=liam@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tz2294@columbia.edu \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
/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