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  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]
Date:   Thu, 30 Aug 2018 15:05:31 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Feng Tang <feng.tang@...el.com>
cc:     Michal Hocko <mhocko@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Ingo Molnar <mingo@...e.hu>,
        "H . Peter Anvin" <hpa@...ux.intel.com>,
        Yinghai Lu <yinghai@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for
 NO_BOOTMEM

On Thu, 30 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 02:49:15PM +0200, Michal Hocko wrote:
> > On Thu 30-08-18 13:54:19, Thomas Gleixner wrote:
> > > On Thu, 30 Aug 2018, Michal Hocko wrote:
> > > > On Thu 30-08-18 12:44:02, Peter Zijlstra wrote:
> > > > > On Thu, Aug 30, 2018 at 05:03:19PM +0800, Feng Tang wrote:
> > > > > > The root cause is that when CONFIG_NO_BOOTMEM=y,  before
> > > > > > e820__memblock_setup() is called there is no memory for bootmem
> > > > > > to allocate,
> > > > > 
> > > > > Which you bloody well asked for by using NO_BOOTMEM=y.
> > > > > 
> > > > > Going down this route; adding hacks for every little thing that does
> > > > > want bootmem, completely defeats the purpose.
> > > > > 
> > > > > If anything, make the earlycon thing depend on NO_BOOTMEM=n. That also
> > > > > solves your problem. No earlycon, no panic.
> > > > 
> > > > Well, there is endeavor to remove bootmem allocator altogether. So
> > > > making earlycon depend on NO_BOOTMEM=n doesn't sound like a good fit to
> > > 
> > > If we want to remove bootmem, then reintroducing it with a static bootmem
> > > section doesn't make any sense at all.
> > 
> > I have actually checked the code now and see what you mean. I thought it
> > would be a single allocation that is needed but that is not the case so
> > the static buffer is not going to fly.
> 
> Exactly! I tried several ways for the static allocation, like in data, in bss
> section, but they all failed, as in the very start of setup_arch():
> 
> 	memblock_reserve(__pa_symbol(_text),
> 		(unsigned long)__bss_stop - (unsigned long)_text);
> 
> Those [_text, __bss_stop] is not able to be used by alloc_bootmem(). And I
> only got this patch, and really appreciate any good suggestions.

And why do you want to use bootmem in the first place? If boot mem is going
away, why are you not fixing the early console crap to NOT use bootmem at
all?

Thanks,

	tglx

Powered by blists - more mailing lists