| 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
| ||
|
Date: Sat, 8 Dec 2007 09:52:07 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Stefano Brivio <stefano.brivio@...imi.it>,
Robert Love <rml@...h9.net>, linux-kernel@...r.kernel.org,
Dave Jones <davej@...hat.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, Michael Buesch <mb@...sch.de>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH] scheduler: fix x86 regression in native_sched_clock
* Nick Piggin <nickpiggin@...oo.com.au> wrote:
> On Saturday 08 December 2007 11:50, Nick Piggin wrote:
>
> > I guess your patch is fairly complex but it should work
>
> I should also add that although complex, it should have a much smaller
> TSC delta window in which the wrong scaling factor can get applied to
> it (I guess it is about as good as you can possibly get). So I do like
> it :)
ok :-)
the scariest bit isnt even the scaling i think - that is a fairly
straightforward and clean PER_CPU-ization of the global scaling factor,
and its hookup with cpufreq events. (and the credit for that goes to
Guillaume Chazarain) We could even split it into two to make it even
less scary and more bisectable.
the scariest bit is the adding of cpu_clock() to kernel/printk.c so late
in the game, and the anti-recursion code i did there. Maybe because this
only affects CONFIG_PRINTK_TIME we could try it even for v2.6.24.
i've now completed a couple of hundred random bootups on x86 overnight,
with the full stack of these patches applied, and no problems.
Could have a really critical look at the two patches below and give your
Reviewed-by line(s) if you agree with having them in v2.6.24? I'd feel a
lot better about this that way :-) I do have the feeling that it makes
printk printout a lot more robust in general, independently of the
cpu_clock() change - especially with more complex consoles like
netconsole or fbcon.
Ingo
-------------------->
Subject: printk: make printk more robust by not allowing recursion
From: Ingo Molnar <mingo@...e.hu>
make printk more robust by allowing recursion only if there's a crash
going on. Also add recursion detection.
I've tested it with an artificially injected printk recursion - instead
of a lockup or spontaneous reboot or other crash, the output was a well
controlled:
[ 41.057335] SysRq : <2>BUG: recent printk recursion!
[ 41.057335] loglevel0-8 reBoot Crashdump show-all-locks(D) tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks
also do all this printk-debug logic with irqs disabled.
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/printk.c | 48 ++++++++++++++++++++++++++++++++++++++----------
1 file changed, 38 insertions(+), 10 deletions(-)
Index: linux/kernel/printk.c
===================================================================
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -628,30 +628,57 @@ asmlinkage int printk(const char *fmt, .
/* cpu currently holding logbuf_lock */
static volatile unsigned int printk_cpu = UINT_MAX;
+const char printk_recursion_bug_msg [] =
+ KERN_CRIT "BUG: recent printk recursion!\n";
+static int printk_recursion_bug;
+
asmlinkage int vprintk(const char *fmt, va_list args)
{
+ static int log_level_unknown = 1;
+ static char printk_buf[1024];
+
unsigned long flags;
- int printed_len;
+ int printed_len = 0;
+ int this_cpu;
char *p;
- static char printk_buf[1024];
- static int log_level_unknown = 1;
boot_delay_msec();
preempt_disable();
- if (unlikely(oops_in_progress) && printk_cpu == smp_processor_id())
- /* If a crash is occurring during printk() on this CPU,
- * make sure we can't deadlock */
- zap_locks();
-
/* This stops the holder of console_sem just where we want him */
raw_local_irq_save(flags);
+ this_cpu = smp_processor_id();
+
+ /*
+ * Ouch, printk recursed into itself!
+ */
+ if (unlikely(printk_cpu == this_cpu)) {
+ /*
+ * If a crash is occurring during printk() on this CPU,
+ * then try to get the crash message out but make sure
+ * we can't deadlock. Otherwise just return to avoid the
+ * recursion and return - but flag the recursion so that
+ * it can be printed at the next appropriate moment:
+ */
+ if (!oops_in_progress) {
+ printk_recursion_bug = 1;
+ goto out_restore_irqs;
+ }
+ zap_locks();
+ }
+
lockdep_off();
spin_lock(&logbuf_lock);
- printk_cpu = smp_processor_id();
+ printk_cpu = this_cpu;
+ if (printk_recursion_bug) {
+ printk_recursion_bug = 0;
+ strcpy(printk_buf, printk_recursion_bug_msg);
+ printed_len = sizeof(printk_recursion_bug_msg);
+ }
/* Emit the output into the temporary buffer */
- printed_len = vscnprintf(printk_buf, sizeof(printk_buf), fmt, args);
+ printed_len += vscnprintf(printk_buf + printed_len,
+ sizeof(printk_buf), fmt, args);
/*
* Copy the output into log_buf. If the caller didn't provide
@@ -744,6 +771,7 @@ asmlinkage int vprintk(const char *fmt,
printk_cpu = UINT_MAX;
spin_unlock(&logbuf_lock);
lockdep_on();
+out_restore_irqs:
raw_local_irq_restore(flags);
}
-------------------->
Subject: sched: fix CONFIG_PRINT_TIME's reliance on sched_clock()
From: Ingo Molnar <mingo@...e.hu>
Stefano Brivio reported weird printk timestamp behavior during
CPU frequency changes:
http://bugzilla.kernel.org/show_bug.cgi?id=9475
fix CONFIG_PRINT_TIME's reliance on sched_clock() and use cpu_clock()
instead.
Reported-and-bisected-by: Stefano Brivio <stefano.brivio@...imi.it>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
kernel/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/kernel/printk.c
===================================================================
--- linux.orig/kernel/printk.c
+++ linux/kernel/printk.c
@@ -707,7 +707,7 @@ asmlinkage int vprintk(const char *fmt,
loglev_char = default_message_loglevel
+ '0';
}
- t = printk_clock();
+ t = cpu_clock(printk_cpu);
nanosec_rem = do_div(t, 1000000000);
tlen = sprintf(tbuf,
"<%c>[%5lu.%06lu] ",
--
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