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] [day] [month] [year] [list]

Message-ID: <20191118112823.GC14255@dhcp22.suse.cz>
Date:   Mon, 18 Nov 2019 12:28:23 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        "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 Fri 15-11-19 15:55:35, Andrew Morton wrote:
> On Tue, 5 Nov 2019 09:43:52 +0100 Michal Hocko <mhocko@...nel.org> wrote:
> 
> > 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.
> > 
> 
> We're late in -rc7.  Should we run with Vincent's original for now?

Yes, that patch is correct on its own. I have still the follow up clean
up on my todo list. I will get to this hopefully soon.

> And I'm wondering why this is -stable -material?  You said
> 
> : Anyway the patch is OK.  Even though this is not a bug strictly
> : speaking it is certainly a suboptimal behavior because zeroying takes
> : time so I would flag this for a stable tree 4.19+.  There is no clear
> : Fixes tag to apply (35fd1eb1e8212 would get closest I guess).
> 
> I'm not seeing any description of any runtime effect of the bug at
> present.  When would unzeroed sparsemem pageframes cause a problem? 
> Could they be visible during deferred initialization or mem hotadd?

The main user visible problem is a memory wastage. The overal amount of
memory should be small. I wouldn't call it a stable material.

-- 
Michal Hocko
SUSE Labs