On Fri, 2010-10-15 at 18:00 +0100, Tim Small wrote:
Package: linux-2.6
Version: 2.6.32-23
Severity: normal
When passing log_buf_len=2M to the kernel, the kernel logs nulls, or
other aparently unitialised RAM to the console, and netconsole.
Any increase in log_buf_len will result in disaster, since OpenVZ will
continue using the old buffer pointer with the new length!
Please can you test this patch, following the instructions at
http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -198,6 +198,9 @@
spin_lock_irqsave(logbuf_lock, flags);
log_buf_len = size;
log_buf = new_log_buf;
+#ifdef CONFIG_VE
+ ve0.log_buf = log_buf;
+#endif
offset = start = min(con_start, log_start);
dest_idx = 0;
@@ -354,9 +357,9 @@
if (ve_log_buf == NULL)
goto out;
count = len;
+ spin_lock_irq(logbuf_lock);
if (count ve_log_buf_len)
count = ve_log_buf_len;
- spin_lock_irq(logbuf_lock);
if (count ve_logged_chars)
count = ve_logged_chars;
if (do_clear)
signature.asc
Description: This is a digitally signed message part
