[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D6BF77E.2030107@sgi.com>
Date: Mon, 28 Feb 2011 11:29:02 -0800
From: Mike Travis <travis@....com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Yinghai Lu <yinghai@...nel.org>,
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>
Subject: Re: [PATCH 1/4] printk: Allocate kernel log buffer earlier
Ingo Molnar wrote:
> * Yinghai Lu <yinghai@...nel.org> wrote:
>
>> + new_addr = memblock_alloc(new_log_buf_len, PAGE_SIZE);
>> + if (new_addr != MEMBLOCK_ERROR)
>> + new_log_buf = __va(new_addr);
>> + else
>> + new_log_buf = alloc_bootmem(new_log_buf_len);
>
> alloc_bootmem() can fail, especially if someone uses a too large boot parameter
> value - and your code does not check for failure.
alloc_bootmem does panic when it can't allocate memory.
Ingo, we have a "uvconfig" script that sets up the boot parameters (there
are many that are needed to be very specific). It sets up the log_buf_len
to be 8M. We will never overflow memory with that.
And if someone is stupid enough to try and allocate a log buffer that
consumes more memory than they have, then they have a different kind of
problem.
>
> 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/
Powered by blists - more mailing lists