linux-kernel - Re: Config NO_BOOTMEM breaks my amd64 box

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]

Date:	Thu, 1 Apr 2010 00:56:58 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	James Morris <jmorris@...ei.org>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, airlied@...ux.ie,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: Config NO_BOOTMEM breaks my amd64 box


* Yinghai Lu <yinghai@...nel.org> wrote:

> On 03/31/2010 03:41 PM, Ingo Molnar wrote:
> > 
> > * Yinghai Lu <yinghai@...nel.org> wrote:
> > 
> >> On 03/31/2010 03:13 PM, Ingo Molnar wrote:
> >>>
> >>> * Yinghai Lu <yinghai@...nel.org> wrote:
> >>>
> >>>> --- linux-2.6.orig/arch/x86/mm/init_32.c
> >>>> +++ linux-2.6/arch/x86/mm/init_32.c
> >>>> @@ -875,7 +875,12 @@ void __init mem_init(void)
> >>>>  	BUG_ON(!mem_map);
> >>>>  #endif
> >>>>  	/* this will put all low memory onto the freelists */
> >>>> +#if defined(CONFIG_NO_BOOTMEM) && defined(MAX_NUMNODES)
> >>>> +	/* In case some 32bit systems don't have RAM installed on node0 */
> >>>> +        totalram_pages += free_all_memory_core_early(MAX_NUMNODES);
> >>>
> >>> (Note: tab whitespace damage)
> >>>
> >>>> +#else
> >>>>  	totalram_pages += free_all_bootmem();
> >>>
> >>> So we get into this branch if CONFIG_NO_BOOTMEM is enabled but MAX_NUMNODES is 
> >>> not defined? Doesnt look right.
> >>
> >> yes. 
> >>
> >> free_all_bootmem() will call
> >> free_all_memory_core_early(NODE_DATA(0)->node_id);
> >>
> >> Thanks
> > 
> > Well and that whole #ifdeffery is disgusting as well - even if the goal was to 
> > remove CONFIG_NO_BOOTMEM ASAP.
> > 
> > Please learn to use proper intermediate helper functions and at minimum put 
> > the conversion ugliness somewhere that doesnt intrude our daily flow in .c 
> > files. The best rule is to _never ever_ put an #ifdef construct into a .c 
> > file. It doesnt matter what the goal if the #ifdef is - such ugliness in code 
> > is never justified.
> > 
> 
> if you agree that i can have one nobootmem.c in mm/

I think what we want is your lmb series, with CONFIG_NO_BOOTMEM eliminated 
altogether and x86 converted to pure (extended) lmb facilities, and without 
any traces of bootmem left in x86.

I.e. a really clean series with no CONFIG_NO_BOOTMEM kind of #ifdef crap left 
around. This means 'nobootmem.c' (albeit saner than an #ifdef jungle) would be 
moot as well.

We tried the dual model as it seemed prudent from a testing/conversion POV 
(and it certainly allowed people to turn the new code off), but it's rather 
ugly and we still have bugs left.

This means that if Linus likes that approach the conversion will be very 
binary and very painful. The other option would be to go back to bootmem and 
forget about the whole nobootmem and lmb thing.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/