linux-kernel - Re: [PATCH v3 4/5] mm: mlock: update the interface to use folios

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: <50cc1bfc-6cee-dc98-7ed9-cc3f0c863c02@suse.cz>
Date:   Thu, 12 Jan 2023 11:55:13 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Lorenzo Stoakes <lstoakes@...il.com>, linux-mm@...ck.org,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Cc:     Matthew Wilcox <willy@...radead.org>,
        Hugh Dickins <hughd@...gle.com>,
        Liam Howlett <liam.howlett@...cle.com>,
        William Kucharski <william.kucharski@...cle.com>,
        Christian Brauner <brauner@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Mike Rapoport <rppt@...nel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v3 4/5] mm: mlock: update the interface to use folios

On 12/26/22 09:44, Lorenzo Stoakes wrote:
> This patch updates the mlock interface to accept folios rather than pages,
> bringing the interface in line with the internal implementation.
> 
> munlock_vma_page() still requires a page_folio() conversion, however this
> is consistent with the existent mlock_vma_page() implementation and a
> product of rmap still dealing in pages rather than folios.
> 
> Signed-off-by: Lorenzo Stoakes <lstoakes@...il.com>

Acked-by: Vlastimil Babka <vbabka@...e.cz>

With some suggestion:

> ---
>  mm/internal.h | 26 ++++++++++++++++----------
>  mm/mlock.c    | 32 +++++++++++++++-----------------
>  mm/swap.c     |  2 +-
>  3 files changed, 32 insertions(+), 28 deletions(-)
> 
> diff --git a/mm/internal.h b/mm/internal.h
> index 1d6f4e168510..8a6e83315369 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -515,10 +515,9 @@ extern int mlock_future_check(struct mm_struct *mm, unsigned long flags,
>   * should be called with vma's mmap_lock held for read or write,
>   * under page table lock for the pte/pmd being added or removed.
>   *
> - * mlock is usually called at the end of page_add_*_rmap(),
> - * munlock at the end of page_remove_rmap(); but new anon
> - * pages are managed by lru_cache_add_inactive_or_unevictable()
> - * calling mlock_new_page().
> + * mlock is usually called at the end of page_add_*_rmap(), munlock at
> + * the end of page_remove_rmap(); but new anon folios are managed by
> + * folio_add_lru_vma() calling mlock_new_folio().
>   *
>   * @compound is used to include pmd mappings of THPs, but filter out
>   * pte mappings of THPs, which cannot be consistently counted: a pte
> @@ -547,15 +546,22 @@ static inline void mlock_vma_page(struct page *page,
>  	mlock_vma_folio(page_folio(page), vma, compound);
>  }
>  
> -void munlock_page(struct page *page);
> -static inline void munlock_vma_page(struct page *page,
> +void munlock_folio(struct folio *folio);
> +
> +static inline void munlock_vma_folio(struct folio *folio,
>  			struct vm_area_struct *vma, bool compound)
>  {
>  	if (unlikely(vma->vm_flags & VM_LOCKED) &&
> -	    (compound || !PageTransCompound(page)))
> -		munlock_page(page);
> +	    (compound || !folio_test_large(folio)))
> +		munlock_folio(folio);
> +}
> +
> +static inline void munlock_vma_page(struct page *page,
> +			struct vm_area_struct *vma, bool compound)
> +{
> +	munlock_vma_folio(page_folio(page), vma, compound);
>  }
> -void mlock_new_page(struct page *page);
> +void mlock_new_folio(struct folio *folio);
>  bool need_mlock_page_drain(int cpu);
>  void mlock_page_drain_local(void);
>  void mlock_page_drain_remote(int cpu);

I think these drain related functions could use a rename as well?
Maybe replace "page" with "fbatch" or "folio_batch"? Even the old name isn't
great, should have been "pagevec".
But maybe it would fit patch 2/5 rather than 4/5 as it's logically internal
even if in a .h file.