Ingo Molnar wrote:
* Mike Travis <travis@xxxxxxx> 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@xxxxxxx>
Reviewed-by: Jack Steiner <steiner@xxxxxxx>
Reviewed-by: Robin Holt <holt@xxxxxxx>
---
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.
Is it really that ugly? I thought in some ways it cleaned it up.
I'm also hesitant to change code for other arch's when I can't test them. This
approach seemed to be the safest.
kernel log buffer size can be configured via the .config so they will not be left
without larger buffers.
We have asked about this, but distros are reluctant to increase memory usage
for their entire installed base. I think we're lucky they bumped it up to 256k
from the default 128k.
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.
There are only two and both remove only redundant information.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
