From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBED4C28B2F for ; Mon, 17 Mar 2025 01:09:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84DF1280002; Sun, 16 Mar 2025 21:09:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FB23280001; Sun, 16 Mar 2025 21:09:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A631280002; Sun, 16 Mar 2025 21:09:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 47A65280001 for ; Sun, 16 Mar 2025 21:09:02 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A1C3B1A129C for ; Mon, 17 Mar 2025 01:09:02 +0000 (UTC) X-FDA: 83229258924.01.3B1A3B8 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf10.hostedemail.com (Postfix) with ESMTP id 9D527C000B for ; Mon, 17 Mar 2025 01:09:00 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y15Z2A5s; spf=pass (imf10.hostedemail.com: domain of nifan.cxl@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=nifan.cxl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742173740; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+xgAMxTm7HfigOCMkwcZ9gBPb1kqXdvU5TNojxRRc20=; b=jFW7UgpyNkjeSrfFz0qTsz11FQ1UcDL8/alqlcIBwuEjvBnB7frVjuzud6N2Sof3ZGIIDO bZQqAHULdjRJdwtfW0dDE5B0CRKT1D29yz9+cLEti5Czg9tcHR+VOntD/L58U7W2gb/e5E OUtZ/He+jy8qHXeNMBjuPjRonQgu5iM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Y15Z2A5s; spf=pass (imf10.hostedemail.com: domain of nifan.cxl@gmail.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=nifan.cxl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742173740; a=rsa-sha256; cv=none; b=wQnZRufiu8C3+ai+9ewqFiZl94c9XvIxIQnZ1xmu+iPDHeQFVzlWV5ACvmFQjn8iKO8lhN c/PXsFNQUPRusknZ4WEdO/pmu7Hl1k7+DAeFYAcugvlFtv43B84kkGvNVnHnwGS70rqzJo i8brBygwqgFykgxYW3BG+ouUkQRB/eQ= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-224171d6826so19018815ad.3 for ; Sun, 16 Mar 2025 18:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1742173739; x=1742778539; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=+xgAMxTm7HfigOCMkwcZ9gBPb1kqXdvU5TNojxRRc20=; b=Y15Z2A5sfXke6W+eWS6GVrkK/xiTVzh5UonqlvrMhoM9V7ZfFh9HcPOa17JkA75Qet Knv5fy8l5098FIDgqsnzKhb8V3oZgBvA2yIoKoVtZvnkJxdGMgEwOf45UTHuP75Hye/T f44Wud4X5x2iuxrIZtW7zgfFdYQQxCyQmJeLfkJBfg5YE1HhXSrZ0lKfcbzt5O3I9fOY H7jZbMGZmEd+EwKV2vvby6mhqBn/+1boOTgz7s/Cz509p7Y713ClVF2PMYXY/XgeEtXi g01ENV7OMDpF3l69lDARrZR8B9mcKbsca8KFPtKbDJs2ev4AusM0LGpkVwa86zPekjBX wcvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742173739; x=1742778539; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+xgAMxTm7HfigOCMkwcZ9gBPb1kqXdvU5TNojxRRc20=; b=AH4hbqeuzSs84HFf1nHnNGoE465/1r9fY9HyvKwuN7Sgqe9cqQeBde0Pn7HEX78SJ0 TsQVS8MSDWKB4n9eRcTVwBUMxtogvd/Be45eKL4l+pxMg5UgjTsVbLWj6SlB4MMKv9R3 H4COJQJcWyNWIqPEnA2tI1J9Q0kgFN5iWftW977C2V6sw0BN/HZpVW0ZKvob9doeNutP LbJmsDPQ4Pts/ho/vVga2O9uCycDLlSVio3eHABxJ2uOTejBWGqz0Ua8XkXRzE46tHO6 SHcfMCHNjOxwExCVaQDMNXob5ZFdNy39KvgxEe7/iKsOHHcb1TkBBFAyKlvqcd4yboGZ pV4A== X-Forwarded-Encrypted: i=1; AJvYcCU979Gb4UQsG3YANOPLXjWtgpuQWRB9tvw2zkWnc6kB9m9PvEsHYSLS33YqzXXnFHNOlrJZQyicVw==@kvack.org X-Gm-Message-State: AOJu0YxDq3eV+Mm30Qc+NvpPwGrSc3uDoy4iVlflLK2dUvBAoxOU3C0q sdaOriMhGIyHrDHOAJvqBFc06ZXa3eSti7c/6XmGsFzhsVsEKHrN X-Gm-Gg: ASbGncv22P1n0ouImJ0evG3fC/TrXq7kIuIC0PxwLXhMDAqDQ2GbePyX7FQRjls1SNx 9jH8QVcUH2Qop8kBvxfZU/HBLKjIhTsZZmoh1jwr+Is2IYT2btFiX4nL8O3PaJscI8kiUfRzi0S ane4VgWWLpej3vQmIy8AZDthgMB1mXGguORka+4nbG9yFxgM9vELSLhcOoAIRfrx4oqUUtI4TON hF32Z0GhLM1WHFkDYpRP4p7Cl+aXZz8uFrr5NPZqMiwPQKNYyNWguigY23ApxIhQ02vNcRNv+lY YOet1FxBWEEpROhc+p4fNWjPZ2cEqQTJww== X-Google-Smtp-Source: AGHT+IE/cCFlfGwrOgbban+cifwtkZH2e1irfVNzdXM6ynsdeqb6iM61hNrMTX1FOVcYWx2Wvv7NZg== X-Received: by 2002:a17:902:e5cb:b0:21f:7a8b:d675 with SMTP id d9443c01a7336-225e0a62f94mr140029755ad.4.1742173739146; Sun, 16 Mar 2025 18:08:59 -0700 (PDT) Received: from fan ([2601:646:8f03:9fee:1b48:1bbe:f0ea:f17]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-225c6888414sm63116515ad.21.2025.03.16.18.08.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Mar 2025 18:08:58 -0700 (PDT) From: Fan Ni X-Google-Original-From: Fan Ni Date: Sun, 16 Mar 2025 18:08:52 -0700 To: "Matthew Wilcox (Oracle)" Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, intel-gfx@lists.freedesktop.org Subject: Re: [PATCH 11/11] fs: Remove aops->writepage Message-ID: References: <20250307135414.2987755-1-willy@infradead.org> <20250307135414.2987755-12-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250307135414.2987755-12-willy@infradead.org> X-Rspam-User: X-Rspamd-Queue-Id: 9D527C000B X-Rspamd-Server: rspam08 X-Stat-Signature: jemqu5yicsxeko3i36cz1my1w7gb7wmy X-HE-Tag: 1742173740-723949 X-HE-Meta: U2FsdGVkX18zpyVg2VcvqYIYAuaog7PSdr8vow3qTlsOX1FCz1DnXOP9qtijnoTBCOHmTyB5ptGccZwkvzRvy1ghH6hB05O59d1lb1wnVzEp0LBHKJxjs/zPJrCaxuYpMjCBCH8iKVuV+4anwryh0IrjJTnGZVLcF5rsVqcKf4fdaWM1vyWLcriIn421GqLXvGhMACXEt8+VM/z4bt3bfuiJd0hLPVXxORpvJC2G5rvqStOwg1AAwwpnIzgGQgNp0/7eVtJ6NpcSBcAgUFCd51Tj01o96j6FRHOkkztOd4u0Ewx/hPKfQnSvJFlo6nGCiq5UMtRlF2yhi6FpbnkmOwA7706DDiNvANS074aT8/8BecnscATlrRF/87xpeG4W/7Y+tgBM4e80B84YHP/eTDikapzubDfOWNFCx4k+0mPQMnkj+XAk4sbQmrZdtV1VlceD2GAUGLLSvYnPicj7aKrgDZ+RyLx4nhtum8MKKgSFBps4BnEtSCGJASVic9U+X6Pn6eewYZUWrypXhC22tjl35S/ju7YspPIvYbBoJacmbdfv9kZjKKFKpXdAcGNp9XEQhTXeZd5Sq5O2iwjI/wblmn/xp4g64bBYcmv0+c4aS6GFTVxFX4tD7HdahDrduf9RuEAbfGjw7vsIfSwDpEj9WS3hsIW7CC++e/hMoSoJw1jkSBB0cRKzmtLOH9chgeY1SsB9aEuRMi4gsoKJ0QhbnxqHBUn0LwjylTcYQcQAE7ignBprgCCW1dVCK0znZuzbs8bH0XWC9RAmkBHC4eClwKCVHFLEQpp47wZUqM3ugYZoRK0GDthJDukFJ4cYu62KASwiGAHRs3pDP+/b0WsZeBhXqWB8dWZnmdKVfvE3kBKsBxukiFgw2pjDVPcXG1vsFTXVGhno+mqoTGbqxZjVmTsdFLTSJs/B9ifoq88yzVd2GiYhdhM+WtEkQyBtnr1Z4B2nBkrQgv9JiCA XZXLuQaG TkbHubN07diuFUeCvG8fa2Q0CHFn2u490Z8X42AKdqoq2m+HZX0lRMIm8OP8JxnGTab6QDZckJ6BL6MBl0AIAmbHJeB36cCDX3DffewrPTY2Qu+YXuwLKpJ41Q3JHot+A8LsDm8J9tMWKzTYeupbLMs/itT39cU0BmNahK8GbS0KkFHRslhIVJ3agmbR2FxI4kRnRGiosAEEsKQd0MsU/b++pAjpAnEuW5LinC5qjAgxNUlaLdbeP31VHZ6HK88F9NwLeEKxgSqm6v/GxkxbtbI4Vzq8A99i4xN3PRqy3RW37s/SrLjHK425ECNyCKM+K5B22LVeMx/rVxXGvwGb1JFh+cEoW9YvsJgdBVi17yuOCHnX3mga9D0Vp97sl+HHqWIQpKp3gwDmf9zB+ivwi2e1pvhnGMZCU8D8Jp/tBy7rr9/uHhJVJoyWj5ejmL17faNwWrIGKd+Th3PUqgAf+CHmAPo8jJqScElHRLZcSPDMrQDZIztb7da74WB5EBI/P2HJvFXkd3nKBT38Epv71TZKuimh0rvWWBREkx0XgUvv3fzI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Mar 07, 2025 at 01:54:11PM +0000, Matthew Wilcox (Oracle) wrote: > All callers and implementations are now removed, so remove the operation > and update the documentation to match. > > Signed-off-by: Matthew Wilcox (Oracle) > --- Hi Matthew, Tried to apply the remaining patches in the patchest (Patch 5-11) which have not picked up by linux-next. It seems we have more to cleanup. For example, I hit the following issue when try to compile ---------------------------------------------------------------- drivers/gpu/drm/ttm/ttm_backup.c: In function ‘ttm_backup_backup_page’: drivers/gpu/drm/ttm/ttm_backup.c:139:39: error: ‘const struct address_space_operations’ has no member named ‘writepage’; did you mean ‘writepages’? 139 | ret = mapping->a_ops->writepage(folio_file_page(to_folio, idx), &wbc); | ^~~~~~~~~ | writepages ---------------------------------------------------------------- Fan > Documentation/admin-guide/cgroup-v2.rst | 2 +- > Documentation/filesystems/fscrypt.rst | 2 +- > Documentation/filesystems/locking.rst | 54 +------------------------ > Documentation/filesystems/vfs.rst | 39 +++++------------- > fs/buffer.c | 4 +- > include/linux/fs.h | 1 - > mm/vmscan.c | 1 - > 7 files changed, 15 insertions(+), 88 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > index 77d80a7e975b..4e10b4084381 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++ b/Documentation/admin-guide/cgroup-v2.rst > @@ -3028,7 +3028,7 @@ Filesystem Support for Writeback > -------------------------------- > > A filesystem can support cgroup writeback by updating > -address_space_operations->writepage[s]() to annotate bio's using the > +address_space_operations->writepages() to annotate bio's using the > following two functions. > > wbc_init_bio(@wbc, @bio) > diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst > index e80329908549..3d22e2db732d 100644 > --- a/Documentation/filesystems/fscrypt.rst > +++ b/Documentation/filesystems/fscrypt.rst > @@ -1409,7 +1409,7 @@ read the ciphertext into the page cache and decrypt it in-place. The > folio lock must be held until decryption has finished, to prevent the > folio from becoming visible to userspace prematurely. > > -For the write path (->writepage()) of regular files, filesystems > +For the write path (->writepages()) of regular files, filesystems > cannot encrypt data in-place in the page cache, since the cached > plaintext must be preserved. Instead, filesystems must encrypt into a > temporary buffer or "bounce page", then write out the temporary > diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst > index 0ec0bb6eb0fb..2e567e341c3b 100644 > --- a/Documentation/filesystems/locking.rst > +++ b/Documentation/filesystems/locking.rst > @@ -249,7 +249,6 @@ address_space_operations > ======================== > prototypes:: > > - int (*writepage)(struct page *page, struct writeback_control *wbc); > int (*read_folio)(struct file *, struct folio *); > int (*writepages)(struct address_space *, struct writeback_control *); > bool (*dirty_folio)(struct address_space *, struct folio *folio); > @@ -280,7 +279,6 @@ locking rules: > ====================== ======================== ========= =============== > ops folio locked i_rwsem invalidate_lock > ====================== ======================== ========= =============== > -writepage: yes, unlocks (see below) > read_folio: yes, unlocks shared > writepages: > dirty_folio: maybe > @@ -309,54 +307,6 @@ completion. > > ->readahead() unlocks the folios that I/O is attempted on like ->read_folio(). > > -->writepage() is used for two purposes: for "memory cleansing" and for > -"sync". These are quite different operations and the behaviour may differ > -depending upon the mode. > - > -If writepage is called for sync (wbc->sync_mode != WBC_SYNC_NONE) then > -it *must* start I/O against the page, even if that would involve > -blocking on in-progress I/O. > - > -If writepage is called for memory cleansing (sync_mode == > -WBC_SYNC_NONE) then its role is to get as much writeout underway as > -possible. So writepage should try to avoid blocking against > -currently-in-progress I/O. > - > -If the filesystem is not called for "sync" and it determines that it > -would need to block against in-progress I/O to be able to start new I/O > -against the page the filesystem should redirty the page with > -redirty_page_for_writepage(), then unlock the page and return zero. > -This may also be done to avoid internal deadlocks, but rarely. > - > -If the filesystem is called for sync then it must wait on any > -in-progress I/O and then start new I/O. > - > -The filesystem should unlock the page synchronously, before returning to the > -caller, unless ->writepage() returns special WRITEPAGE_ACTIVATE > -value. WRITEPAGE_ACTIVATE means that page cannot really be written out > -currently, and VM should stop calling ->writepage() on this page for some > -time. VM does this by moving page to the head of the active list, hence the > -name. > - > -Unless the filesystem is going to redirty_page_for_writepage(), unlock the page > -and return zero, writepage *must* run set_page_writeback() against the page, > -followed by unlocking it. Once set_page_writeback() has been run against the > -page, write I/O can be submitted and the write I/O completion handler must run > -end_page_writeback() once the I/O is complete. If no I/O is submitted, the > -filesystem must run end_page_writeback() against the page before returning from > -writepage. > - > -That is: after 2.5.12, pages which are under writeout are *not* locked. Note, > -if the filesystem needs the page to be locked during writeout, that is ok, too, > -the page is allowed to be unlocked at any point in time between the calls to > -set_page_writeback() and end_page_writeback(). > - > -Note, failure to run either redirty_page_for_writepage() or the combination of > -set_page_writeback()/end_page_writeback() on a page submitted to writepage > -will leave the page itself marked clean but it will be tagged as dirty in the > -radix tree. This incoherency can lead to all sorts of hard-to-debug problems > -in the filesystem like having dirty inodes at umount and losing written data. > - > ->writepages() is used for periodic writeback and for syscall-initiated > sync operations. The address_space should start I/O against at least > ``*nr_to_write`` pages. ``*nr_to_write`` must be decremented for each page > @@ -364,8 +314,8 @@ which is written. The address_space implementation may write more (or less) > pages than ``*nr_to_write`` asks for, but it should try to be reasonably close. > If nr_to_write is NULL, all dirty pages must be written. > > -writepages should _only_ write pages which are present on > -mapping->io_pages. > +writepages should _only_ write pages which are present in > +mapping->i_pages. > > ->dirty_folio() is called from various places in the kernel when > the target folio is marked as needing writeback. The folio cannot be > diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst > index ae79c30b6c0c..f66a4e706b17 100644 > --- a/Documentation/filesystems/vfs.rst > +++ b/Documentation/filesystems/vfs.rst > @@ -716,9 +716,8 @@ page lookup by address, and keeping track of pages tagged as Dirty or > Writeback. > > The first can be used independently to the others. The VM can try to > -either write dirty pages in order to clean them, or release clean pages > -in order to reuse them. To do this it can call the ->writepage method > -on dirty pages, and ->release_folio on clean folios with the private > +release clean pages in order to reuse them. To do this it can call > +->release_folio on clean folios with the private > flag set. Clean pages without PagePrivate and with no external references > will be released without notice being given to the address_space. > > @@ -731,8 +730,8 @@ maintains information about the PG_Dirty and PG_Writeback status of each > page, so that pages with either of these flags can be found quickly. > > The Dirty tag is primarily used by mpage_writepages - the default > -->writepages method. It uses the tag to find dirty pages to call > -->writepage on. If mpage_writepages is not used (i.e. the address > +->writepages method. It uses the tag to find dirty pages to > +write back. If mpage_writepages is not used (i.e. the address > provides its own ->writepages) , the PAGECACHE_TAG_DIRTY tag is almost > unused. write_inode_now and sync_inode do use it (through > __sync_single_inode) to check if ->writepages has been successful in > @@ -756,23 +755,23 @@ pages, however the address_space has finer control of write sizes. > > The read process essentially only requires 'read_folio'. The write > process is more complicated and uses write_begin/write_end or > -dirty_folio to write data into the address_space, and writepage and > +dirty_folio to write data into the address_space, and > writepages to writeback data to storage. > > Adding and removing pages to/from an address_space is protected by the > inode's i_mutex. > > When data is written to a page, the PG_Dirty flag should be set. It > -typically remains set until writepage asks for it to be written. This > +typically remains set until writepages asks for it to be written. This > should clear PG_Dirty and set PG_Writeback. It can be actually written > at any point after PG_Dirty is clear. Once it is known to be safe, > PG_Writeback is cleared. > > Writeback makes use of a writeback_control structure to direct the > -operations. This gives the writepage and writepages operations some > +operations. This gives the writepages operation some > information about the nature of and reason for the writeback request, > and the constraints under which it is being done. It is also used to > -return information back to the caller about the result of a writepage or > +return information back to the caller about the result of a > writepages request. > > > @@ -819,7 +818,6 @@ cache in your filesystem. The following members are defined: > .. code-block:: c > > struct address_space_operations { > - int (*writepage)(struct page *page, struct writeback_control *wbc); > int (*read_folio)(struct file *, struct folio *); > int (*writepages)(struct address_space *, struct writeback_control *); > bool (*dirty_folio)(struct address_space *, struct folio *); > @@ -848,25 +846,6 @@ cache in your filesystem. The following members are defined: > int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter); > }; > > -``writepage`` > - called by the VM to write a dirty page to backing store. This > - may happen for data integrity reasons (i.e. 'sync'), or to free > - up memory (flush). The difference can be seen in > - wbc->sync_mode. The PG_Dirty flag has been cleared and > - PageLocked is true. writepage should start writeout, should set > - PG_Writeback, and should make sure the page is unlocked, either > - synchronously or asynchronously when the write operation > - completes. > - > - If wbc->sync_mode is WB_SYNC_NONE, ->writepage doesn't have to > - try too hard if there are problems, and may choose to write out > - other pages from the mapping if that is easier (e.g. due to > - internal dependencies). If it chooses not to start writeout, it > - should return AOP_WRITEPAGE_ACTIVATE so that the VM will not > - keep calling ->writepage on that page. > - > - See the file "Locking" for more details. > - > ``read_folio`` > Called by the page cache to read a folio from the backing store. > The 'file' argument supplies authentication information to network > @@ -909,7 +888,7 @@ cache in your filesystem. The following members are defined: > given and that many pages should be written if possible. If no > ->writepages is given, then mpage_writepages is used instead. > This will choose pages from the address space that are tagged as > - DIRTY and will pass them to ->writepage. > + DIRTY and will write them back. > > ``dirty_folio`` > called by the VM to mark a folio as dirty. This is particularly > diff --git a/fs/buffer.c b/fs/buffer.c > index c7abb4a029dc..b99dc69dba37 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -2695,7 +2695,7 @@ int block_truncate_page(struct address_space *mapping, > EXPORT_SYMBOL(block_truncate_page); > > /* > - * The generic ->writepage function for buffer-backed address_spaces > + * The generic write folio function for buffer-backed address_spaces > */ > int block_write_full_folio(struct folio *folio, struct writeback_control *wbc, > void *get_block) > @@ -2715,7 +2715,7 @@ int block_write_full_folio(struct folio *folio, struct writeback_control *wbc, > > /* > * The folio straddles i_size. It must be zeroed out on each and every > - * writepage invocation because it may be mmapped. "A file is mapped > + * writeback invocation because it may be mmapped. "A file is mapped > * in multiples of the page size. For a file that is not a multiple of > * the page size, the remaining memory is zeroed when mapped, and > * writes to that region are not written out to the file." > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 110d95d04299..26ce65c4a003 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -433,7 +433,6 @@ static inline bool is_sync_kiocb(struct kiocb *kiocb) > } > > struct address_space_operations { > - int (*writepage)(struct page *page, struct writeback_control *wbc); > int (*read_folio)(struct file *, struct folio *); > > /* Write back some dirty pages from this mapping. */ > diff --git a/mm/vmscan.c b/mm/vmscan.c > index e9f84fa31b9a..7e79ca975c9d 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -643,7 +643,6 @@ typedef enum { > > /* > * pageout is called by shrink_folio_list() for each dirty folio. > - * Calls ->writepage(). > */ > static pageout_t pageout(struct folio *folio, struct address_space *mapping, > struct swap_iocb **plug, struct list_head *folio_list) > -- > 2.47.2 > -- Fan Ni