Re: [PATCH 1/5] mm: truncate_complete_page is not existed anymore

[Jan Kara <jack@suse.cz>]

On Tue 03-11-20 05:03:30, Yang Shi wrote:
> The commit 9f4e41f4717832e34cca153ced62b4a1d7e26c0e ("mm: refactor
> truncate_complete_page()") refactored truncate_complete_page(), and it
> is not existed anymore, correct the comment in vmscan and migrate to avoid
> confusion.
> 
> Signed-off-by: Yang Shi <shy828301@gmail.com>

Thanks! Looks good to me. You can add:

Reviewed-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  mm/migrate.c | 2 +-
>  mm/vmscan.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 5ca5842df5db..8a2e7e19e27b 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1106,7 +1106,7 @@ static int __unmap_and_move(struct page *page, struct page *newpage,
>  	 * and treated as swapcache but it has no rmap yet.
>  	 * Calling try_to_unmap() against a page->mapping==NULL page will
>  	 * trigger a BUG.  So handle it here.
> -	 * 2. An orphaned page (see truncate_complete_page) might have
> +	 * 2. An orphaned page (see truncate_cleanup_page) might have
>  	 * fs-private metadata. The page can be picked up due to memory
>  	 * offlining.  Everywhere else except page reclaim, the page is
>  	 * invisible to the vm, so the page can not be migrated.  So try to
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 1b8f0e059767..165cca87edc8 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1393,7 +1393,7 @@ static unsigned int shrink_page_list(struct list_head *page_list,
>  		 *
>  		 * Rarely, pages can have buffers and no ->mapping.  These are
>  		 * the pages which were not successfully invalidated in
> -		 * truncate_complete_page().  We try to drop those buffers here
> +		 * truncate_cleanup_page().  We try to drop those buffers here
>  		 * and if that worked, and the page is no longer mapped into
>  		 * process address space (page_count == 1) it can be freed.
>  		 * Otherwise, leave the page on the LRU so it is swappable.
> -- 
> 2.26.2
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR