linux-kernel - Re: linux-next: parsing mem=700M broken

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:	Tue, 23 Dec 2008 15:33:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Hugh Dickins <hugh@...itas.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: linux-next: parsing mem=700M broken


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

> On Mon, Dec 22, 2008 at 7:06 PM, Hugh Dickins <hugh@...itas.com> wrote:
> > Hi Rusty,
> >
> > I find that bootparam "mem=700M" isn't working in linux-next or mmotm,
> > and have bisected it down to your patch below; but now I'm off to bed
> > without working out just what goes wrong (I'll bet it's the "=").
> >
> > Hugh
> >
> > commit 5c886584a758edba7e25ad9df974cf15a4a1f59d
> > Author: Rusty Russell <rusty@...tcorp.com.au>
> > Date:   Wed Dec 3 13:34:34 2008 +1030
> >
> >    Call early_param earlier.
> >
> >    We delete all the arch calls: we call it from start_kernel earlier
> >    now.  We also no longer take a temporary copy, but parse in place.
> >
> >    Note: IA64 needs to parse "machvec=" before other commandline options
> >    but machvec_init_from_cmdline() needs efi_init() and io_port_init(),
> >    so they are all moved into arch_get_boot_command_line().
> >
> 
> yeah, you are right.
> 
> static int __init parse_memopt(char *p)
> {
>         u64 mem_size;
> 
>         if (!p)
>                 return -EINVAL;
> 
> #ifdef CONFIG_X86_32
>         if (!strcmp(p, "nopentium")) {
>                 setup_clear_cpu_cap(X86_FEATURE_PSE);
>                 return 0;
>         }
> #endif
> 
>         userdef = 1;
>         mem_size = memparse(p, &p);
>         e820_remove_range(mem_size, ULLONG_MAX - mem_size, E820_RAM, 1);
> 
>         return 0;
> }
> early_param("mem", parse_memopt);
> 
> 
> in x86 we use that param analyser much later ( after we check the e820 
> table..)
> 
> other cpu flag will be overwrite too..
> 
> anyway, this patch is not go through x86 tip..., some strange!

the x86 impact is incidental:

 arch/avr32/kernel/setup.c   |    2 --
 arch/ia64/kernel/setup.c    |   18 ++++++++----------
 arch/m68k/kernel/setup.c    |    2 --
 arch/mips/kernel/setup.c    |    2 --
 arch/powerpc/kernel/prom.c  |    1 -
 arch/s390/kernel/setup.c    |    2 --
 arch/sh/kernel/setup.c      |    2 --
 arch/sparc/kernel/setup.c   |    3 ---
 arch/sparc64/kernel/setup.c |    3 ---
 arch/x86/kernel/setup.c     |    3 ---
 include/linux/init.h        |    2 --
 init/main.c                 |   21 ++++-----------------
 12 files changed, 12 insertions(+), 49 deletions(-)

we generally do not require patches to go via the x86 tree that just 
happen to touch it with the intention of not breaking anything.

Rusty, will you fix or revert it?

	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/