All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Guo Weikang <guoweikang.kernel@gmail.com>
Cc: Mike Rapoport <rppt@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/memmap: Prevent double scanning of memmap by kmemleak
Date: Thu, 2 Jan 2025 17:15:43 +0000	[thread overview]
Message-ID: <Z3bJv_zLdHJaS2LW@arm.com> (raw)
In-Reply-To: <20250102065704.647693-1-guoweikang.kernel@gmail.com>

On Thu, Jan 02, 2025 at 02:57:03PM +0800, Guo Weikang wrote:
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 673d5cae7c81..b0483c534ef7 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -375,7 +375,13 @@ static inline int memblock_get_region_node(const struct memblock_region *r)
>  }
>  #endif /* CONFIG_NUMA */
>  
> -/* Flags for memblock allocation APIs */
> +/*
> + * Flags for memblock allocation APIs
> + * MEMBLOCK_ALLOC_ANYWHERE and MEMBLOCK_ALLOC_ACCESSIBLE
> + * indicates wheather the allocation is limited by memblock.current_limit.
> + * MEMBLOCK_ALLOC_NOLEAKTRACE not only indicates that it does not need to
> + * be scanned by kmemleak, but also implies MEMBLOCK_ALLOC_ACCESSIBLE
> + */

I'd keep the comment short here, something like:

/*
 * MEMBLOCK_ALLOC_NOLEAKTRACE avoids kmemleak tracing. It implies
 * MEMBLOCK_ALLOC_ACCESSIBLE.
 */

>  #define MEMBLOCK_ALLOC_ANYWHERE	(~(phys_addr_t)0)
>  #define MEMBLOCK_ALLOC_ACCESSIBLE	0
>  #define MEMBLOCK_ALLOC_NOLEAKTRACE	1
> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index 24b68b425afb..71b58f5f2492 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1580,6 +1580,10 @@ static void __init free_area_init_core(struct pglist_data *pgdat)
>  	}
>  }
>  
> +/*
> + * Kmemleak will explicitly scan mem_map by traversing all valid `struct *page`,
> + * so memblock does not need to be added to the scan list.
> + */
>  void __init *memmap_alloc(phys_addr_t size, phys_addr_t align,
>  			  phys_addr_t min_addr, int nid, bool exact_nid)
>  {
> @@ -1587,11 +1591,11 @@ void __init *memmap_alloc(phys_addr_t size, phys_addr_t align,
>  
>  	if (exact_nid)
>  		ptr = memblock_alloc_exact_nid_raw(size, align, min_addr,
> -						   MEMBLOCK_ALLOC_ACCESSIBLE,
> +						   MEMBLOCK_ALLOC_NOLEAKTRACE,
>  						   nid);
>  	else
>  		ptr = memblock_alloc_try_nid_raw(size, align, min_addr,
> -						 MEMBLOCK_ALLOC_ACCESSIBLE,
> +						 MEMBLOCK_ALLOC_NOLEAKTRACE,
>  						 nid);
>  
>  	if (ptr && size > 0)
> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> index cec67c5f37d8..b6ac9b1d4ff7 100644
> --- a/mm/sparse-vmemmap.c
> +++ b/mm/sparse-vmemmap.c
> @@ -27,25 +27,10 @@
>  #include <linux/spinlock.h>
>  #include <linux/vmalloc.h>
>  #include <linux/sched.h>
> -
> +#include "internal.h"
>  #include <asm/dma.h>
>  #include <asm/pgalloc.h>
>  
> -/*
> - * Allocate a block of memory to be used to back the virtual memory map
> - * or to back the page tables that are used to create the mapping.
> - * Uses the main allocators if they are available, else bootmem.
> - */
> -
> -static void * __ref __earlyonly_bootmem_alloc(int node,
> -				unsigned long size,
> -				unsigned long align,
> -				unsigned long goal)
> -{
> -	return memblock_alloc_try_nid_raw(size, align, goal,
> -					       MEMBLOCK_ALLOC_ACCESSIBLE, node);
> -}
> -
>  void * __meminit vmemmap_alloc_block(unsigned long size, int node)
>  {
>  	/* If the main allocator is up use that, fallback to bootmem. */
> @@ -66,8 +51,7 @@ void * __meminit vmemmap_alloc_block(unsigned long size, int node)
>  		}
>  		return NULL;
>  	} else
> -		return __earlyonly_bootmem_alloc(node, size, size,
> -				__pa(MAX_DMA_ADDRESS));
> +		return memmap_alloc(size, size, __pa(MAX_DMA_ADDRESS), node, false);
>  }

As the kernel test robot reported, the __ref annotation for
__earlyonly_bootmem_alloc() is still needed, otherwise you get a warning
that a __meminit function (vmemmap_alloc_block()) is calling an __init
one (memmap_alloc()). So I think it's better if you keep this function.
Maybe get it to call memmap_alloc() instead of
memblock_alloc_try_nid_raw().

-- 
Catalin


  parent reply	other threads:[~2025-01-02 17:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-02  6:57 [PATCH] mm/memmap: Prevent double scanning of memmap by kmemleak Guo Weikang
2025-01-02  9:12 ` kernel test robot
2025-01-02 17:15 ` Catalin Marinas [this message]
2025-01-03  0:01   ` Weikang Guo
2025-01-03 10:56 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z3bJv_zLdHJaS2LW@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=guoweikang.kernel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.