| 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, 15 Jan 2011 16:29:13 +0800 From: Dave Young <hidave.darkstar@...il.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Don Zickus <dzickus@...hat.com>, Ingo Molnar <mingo@...e.hu>, fweisbec@...il.com, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/2] panic: ratelimit panic messages On Thu, Jan 6, 2011 at 6:51 AM, Andrew Morton <akpm@...ux-foundation.org> wrote: > On Tue, 4 Jan 2011 22:38:30 -0500 > Don Zickus <dzickus@...hat.com> wrote: > >> Sometimes when things go bad, so much spew is coming on the console it is hard >> to figure out what happened. This patch allows you to ratelimit the panic >> messages with the intent that the first panic message will provide the info >> we need to figure out what happened. >> >> Adds new kernel param 'panic_ratelimit=on/<integer in seconds>' >> > > Terminological whinge: panic() is a specific kernel API which ends up > doing a sort-of-oops thing. So the graph is > > panic -> oops > other-things -> oops > > Your patch doesn't affect only panics - it also affects oops, BUG(), > etc. So I'd suggest that this patch should do s/panic/oops/g. > >> --- >> Documentation/kernel-parameters.txt | 6 ++++++ >> kernel/panic.c | 30 ++++++++++++++++++++++++++++++ >> 2 files changed, 36 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt >> index 316c723..1416964 100644 >> --- a/Documentation/kernel-parameters.txt >> +++ b/Documentation/kernel-parameters.txt >> @@ -1807,6 +1807,12 @@ and is between 256 and 4096 characters. It is defined in the file >> panic= [KNL] Kernel behaviour on panic >> Format: <timeout> >> >> + panic_ratelimit= [KNL] ratelimit the panic messages >> + Useful for slowing down multiple panics to capture >> + the first one before it scrolls off the screen >> + Format: "on" or some integer in seconds >> + "on" defaults to 10 minutes >> + > > We keep on hacking away at this and things never seem to get much > better. It's still the case that a large number of our oops reports > are damaged because the important parts of the oops trace scrolled off > the screen. > > I therefore propose > > oops_lines_delay=N,M > > which will cause the kernel to pause for M milliseconds after emitting > N lines of oops output. Bonus marks for handling linewrap! I ever try to do similar things to printk_delay, something like printk_lines_delay, or give printk_delay one more parameter of lines. What do you think about this approach? > > Start the line counter at oops_begin() or thereabouts and then do the > delay after N lines have been emitted. I guess that counter should > _not_ be invalidated in oops_end(): if the oops generates 12 lines and > then another 100 lines of random printk crap are printed, we still want > to put a pause after the 13th line of that random crap, so we can view > the oops. > > The oops_lines_delay implemetnation should count lines from all CPUs > and should block all CPUs during the delay. > > I think this would solve the problem which you're seeing, as well as > the much larger my-oops-scrolled-off problem? > > -- > 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/ > -- Regards dave -- 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