linux-kernel - Re: [PATCH] mm/sparse: Consistently do not zero memmap

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: <20191105084352.GJ22672@dhcp22.suse.cz>
Date:   Tue, 5 Nov 2019 09:43:52 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Vincent Whitchurch <vincent.whitchurch@...s.com>
Cc:     Pavel Tatashin <pasha.tatashin@...een.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "osalvador@...e.de" <osalvador@...e.de>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm/sparse: Consistently do not zero memmap

On Mon 04-11-19 16:51:26, Vincent Whitchurch wrote:
> On Thu, Oct 31, 2019 at 08:25:55AM +0100, Michal Hocko wrote:
> > On Wed 30-10-19 18:31:23, Michal Hocko wrote:
> > [...]
> > > What about this? It still aligns to the size but that should be
> > > correctly done to the section size level.
> > > 
> > > diff --git a/mm/sparse.c b/mm/sparse.c
> > > index 72f010d9bff5..ab1e6175ac9a 100644
> > > --- a/mm/sparse.c
> > > +++ b/mm/sparse.c
> > > @@ -456,8 +456,7 @@ struct page __init *__populate_section_memmap(unsigned long pfn,
> > >  	if (map)
> > >  		return map;
> > >  
> > > -	map = memblock_alloc_try_nid(size,
> > > -					  PAGE_SIZE, addr,
> > > +	map = memblock_alloc_try_nid(size, size, addr,
> > >  					  MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> > >  	if (!map)
> > >  		panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d from=%pa\n",
> > > @@ -474,8 +473,13 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
> > >  {
> > >  	phys_addr_t addr = __pa(MAX_DMA_ADDRESS);
> > >  	WARN_ON(sparsemap_buf);	/* forgot to call sparse_buffer_fini()? */
> > > +	/*
> > > +	 * Pre-allocated buffer is mainly used by __populate_section_memmap
> > > +	 * and we want it to be properly aligned to the section size - this is
> > > +	 * especially the case for VMEMMAP which maps memmap to PMDs
> > > +	 */
> > >  	sparsemap_buf =
> > > -		memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> > > +		memblock_alloc_try_nid_raw(size, section_map_size(),
> > >  						addr,
> > >  						MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> > >  	sparsemap_buf_end = sparsemap_buf + size;
> >
> > Vincent, could you give this a try please? It would be even better if
> > you could add some debugging to measure the overhead. Let me know if you
> > need any help with a debugging patch.
> 
> I've tested this patch and it works on my platform:  The allocations
> from sparse_buffer_alloc() now succeed and the fallback path is not
> taken.

Thanks a lot. I will try to prepare the full patch with a proper
changelog sometimes this week.

> I'm not sure what kind of overhead you're interested in.

The memory overhead when the sparsemap_buf PAGE_SIZE alignment is in
place. In other words (ptr - sparsemap_buf) in sparse_buffer_alloc. If
the sparsemap_buf was properly aligned then the diff should be 0.

-- 
Michal Hocko
SUSE Labs