linux-kernel - Re: [PATCH 3/4] mm: introduce memmap_alloc() to unify memory map allocation

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: <YO/RVo7Kh2mIXZFp@kernel.org>
Date:   Thu, 15 Jul 2021 09:10:30 +0300
From:   Mike Rapoport <rppt@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Michal Simek <monstr@...str.eu>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 3/4] mm: introduce memmap_alloc() to unify memory map
 allocation

On Wed, Jul 14, 2021 at 03:32:08PM -0700, Andrew Morton wrote:
> On Wed, 14 Jul 2021 15:37:38 +0300 Mike Rapoport <rppt@...nel.org> wrote:
> 
> > From: Mike Rapoport <rppt@...ux.ibm.com>
> > 
> > There are several places that allocate memory for the memory map:
> > alloc_node_mem_map() for FLATMEM, sparse_buffer_init() and
> > __populate_section_memmap() for SPARSEMEM.
> > 
> > The memory allocated in the FLATMEM case is zeroed and it is never
> > poisoned, regardless of CONFIG_PAGE_POISON setting.
> > 
> > The memory allocated in the SPARSEMEM cases is not zeroed and it is
> > implicitly poisoned inside memblock if CONFIG_PAGE_POISON is set.
> > 
> > Introduce memmap_alloc() wrapper for memblock allocators that will be used
> > for both FLATMEM and SPARSEMEM cases and will makei memory map zeroing and
> > poisoning consistent for different memory models.
> > 
> > ...
> >
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -6730,6 +6730,26 @@ static void __init memmap_init(void)
> >  		init_unavailable_range(hole_pfn, end_pfn, zone_id, nid);
> >  }
> >  
> > +void __init *memmap_alloc(phys_addr_t size, phys_addr_t align,
> > +			  phys_addr_t min_addr, int nid, bool exact_nid)
> > +{
> > +	void *ptr;
> > +
> > +	if (exact_nid)
> > +		ptr = memblock_alloc_exact_nid_raw(size, align, min_addr,
> > +						   MEMBLOCK_ALLOC_ACCESSIBLE,
> > +						   nid);
> > +	else
> > +		ptr = memblock_alloc_try_nid_raw(size, align, min_addr,
> > +						 MEMBLOCK_ALLOC_ACCESSIBLE,
> > +						 nid);
> > +
> > +	if (ptr && size > 0)
> > +		page_init_poison(ptr, size);
> > +
> > +	return ptr;
> > +}
> > +
> >  static int zone_batchsize(struct zone *zone)
> >  {
> >  #ifdef CONFIG_MMU
> > @@ -7501,8 +7521,8 @@ static void __ref alloc_node_mem_map(struct pglist_data *pgdat)
> >  		end = pgdat_end_pfn(pgdat);
> >  		end = ALIGN(end, MAX_ORDER_NR_PAGES);
> >  		size =  (end - start) * sizeof(struct page);
> > -		map = memblock_alloc_node(size, SMP_CACHE_BYTES,
> > -					  pgdat->node_id);
> > +		map = memmap_alloc(size, SMP_CACHE_BYTES, MEMBLOCK_LOW_LIMIT,
> > +				   pgdat->node_id, false);
> 
> Mostly offtopic, but...  Why is alloc_node_mem_map() marked __ref? 

Once free_area_init_node() was __meminit, I stopped digging at that point.

> afaict it can be __init?

Yes.

-- 
Sincerely yours,
Mike.