linux-kernel - Re: [PATCH 1/4] printk: Allocate kernel log buffer earlier

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:	Sun, 27 Feb 2011 13:09:49 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Travis <travis@....com>
Cc:	David Rientjes <rientjes@...gle.com>,
	Jack Steiner <steiner@....com>, Robin Holt <holt@....com>,
	Len Brown <len.brown@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Yinghai Lu <yhlu.kernel@...il.com>, linux-acpi@...r.kernel.org,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH 1/4] printk: Allocate kernel log buffer earlier


* Mike Travis <travis@....com> wrote:

> On larger systems, because of the numerous ACPI, Bootmem and EFI
> messages, the static log buffer overflows before the larger one
> specified by the log_buf_len param is allocated.  Minimize the
> potential for overflow by allocating the new log buffer as soon
> as possible.
> 
> We do this by changing the log_buf_len from an early_param to a
> _setup param.  But _setup params are processed before the
> alloc_bootmem is available, so this function will now just save
> the requested log buf len.  The real work routine (setup_log_buf)
> is called after bootmem is available.
> 
> Signed-off-by: Mike Travis <travis@....com>
> Reviewed-by: Jack Steiner <steiner@....com>
> Reviewed-by: Robin Holt <holt@....com>
> ---
>  arch/x86/kernel/setup.c |    5 +++
>  include/linux/printk.h  |    4 ++
>  init/main.c             |    1 
>  kernel/printk.c         |   75 ++++++++++++++++++++++++++++--------------------
>  4 files changed, 54 insertions(+), 31 deletions(-)

Well, the modern allocation method is memblock - available on all major 
architectures.

You could avoid all this ugly workaround of bootmem limitations by moving the 
allocation to memblock_alloc() and desupporting the log_buf_len= boot parameter
on non-memblock architectures.

kernel log buffer size can be configured via the .config so they will not be left 
without larger buffers.

Doing this should also have the advantage of getting all the early x86 messages into 
the larger buffer already, reducing the pressure to apply some of the other patches 
in your series.

Thanks,

	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/