Re: [RFC PATCH 3/4] perf: Use vmalloc_to_folio()

[Lorenzo Stoakes <lstoakes@gmail.com>]

On Mon, Aug 21, 2023 at 09:20:15PM +0100, Matthew Wilcox (Oracle) wrote:
> Eliminate a use of page->mapping by using vmalloc_to_folio() instead.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> ---
>  include/linux/mm.h          | 5 +++++
>  kernel/events/ring_buffer.c | 4 ++--
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 840bae5f23b6..7d84a2843193 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1134,6 +1134,11 @@ int region_intersects(resource_size_t offset, size_t size, unsigned long flags,
>  struct page *vmalloc_to_page(const void *addr);
>  unsigned long vmalloc_to_pfn(const void *addr);
>
> +static inline struct folio *vmalloc_to_folio(const void *addr)
> +{
> +	return page_folio(vmalloc_to_page(addr));
> +}
> +

Total nit, and quite possibly unnecessary, but it might be nice to have a
comment pointing out that vmalloc_to_page can and will return tail pages hence
the need for page_folio() and thus _compound_head().

This makes me wonder about a typedef or wrapper type which explicitly indicates
that a function is _intentionally_ returning something that might be a head or a
tail page. But perhaps once foliofication is complete, this is what struct page
or its memdesc replacement will become?

>  /*
>   * Determine if an address is within the vmalloc range
>   *
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index c73add132618..56939dc3bf33 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -873,9 +873,9 @@ __perf_mmap_to_page(struct perf_buffer *rb, unsigned long pgoff)
>
>  static void perf_mmap_unmark_page(void *addr)
>  {
> -	struct page *page = vmalloc_to_page(addr);
> +	struct folio *folio = vmalloc_to_folio(addr);
>
> -	page->mapping = NULL;
> +	folio->mapping = NULL;
>  }
>
>  static void rb_free_work(struct work_struct *work)
> --
> 2.40.1
>

Reviewed-by: Lorenzo Stoakes <lstoakes@gmail.com>