linux-kernel - Re: [PATCH v1 3/6] mm/migrate: don't call folio_putback_active

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ff33a4f9-5afb-418c-a0e9-488d72f04a58@linux.alibaba.com>
Date: Mon, 13 Jan 2025 15:00:35 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
 Muchun Song <muchun.song@...ux.dev>,
 "Matthew Wilcox (Oracle)" <willy@...radead.org>
Subject: Re: [PATCH v1 3/6] mm/migrate: don't call
 folio_putback_active_hugetlb() on dst hugetlb folio



On 2025/1/11 02:21, David Hildenbrand wrote:
> We replaced a simple put_page() by a putback_active_hugepage() call in
> commit 3aaa76e125c1 ("mm: migrate: hugetlb: putback destination hugepage
> to active list"), to set the "active" flag on the dst hugetlb folio.
> 
> Nowadays, we decoupled the "active" list from the flag, by calling the
> flag "migratable".
> 
> Calling "putback" on something that wasn't allocated is weird and not
> future proof, especially if we might reach that path when migration failed
> and we just want to free the freshly allocated hugetlb folio.
> 
> Let's simply set the "migratable" flag in move_hugetlb_state(), where we
> know that allocation succeeded, and use simple folio_put() to return
> our reference.
> 
> Do we need the hugetlb_lock for setting that flag? Staring at other
> users of folio_set_hugetlb_migratable(), it does not look like it. After
> all, the dst folio should already be on the active list, and we are not
> modifying that list.
> 
> Signed-off-by: David Hildenbrand <david@...hat.com>
> ---
>   mm/hugetlb.c | 5 +++++
>   mm/migrate.c | 8 ++++----
>   2 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index da98d671088d0..b24ccf8ecbf38 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -7529,6 +7529,11 @@ void move_hugetlb_state(struct folio *old_folio, struct folio *new_folio, int re
>   		}
>   		spin_unlock_irq(&hugetlb_lock);
>   	}
> +	/*
> +	 * Our old folio is isolated and has "migratable" cleared until it
> +	 * is putback. As migration succeeded, set the new folio "migratable".
> +	 */
> +	folio_set_hugetlb_migratable(new_folio);
>   }
>   
>   static void hugetlb_unshare_pmds(struct vm_area_struct *vma,
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 80887cadb2774..7e23e78f1e57b 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1542,14 +1542,14 @@ static int unmap_and_move_huge_page(new_folio_t get_new_folio,
>   		list_move_tail(&src->lru, ret);
>   
>   	/*
> -	 * If migration was not successful and there's a freeing callback, use
> -	 * it.  Otherwise, put_page() will drop the reference grabbed during
> -	 * isolation.
> +	 * If migration was not successful and there's a freeing callback,
> +	 * return the folio to that special allocator. Otherwise, simply drop
> +	 * our additional reference.
>   	 */
>   	if (put_new_folio)
>   		put_new_folio(dst, private);
>   	else
> -		folio_putback_active_hugetlb(dst);
> +		folio_put(dst);

IIUC, after the changes, so the 'dst' folio might not be added into the 
'h->hugepage_activelist' list (if the 'dst' is temporarily allocated), 
Could this cause any side effects?