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
| ||
|
Message-Id: <1255952922.32489.505.camel@localhost> Date: Mon, 19 Oct 2009 14:48:42 +0300 From: Artem Bityutskiy <dedekind1@...il.com> To: Simon Kagstrom <simon.kagstrom@...insight.net> Cc: Ingo Molnar <mingo@...e.hu>, linux-mtd <linux-mtd@...ts.infradead.org>, Linus Torvalds <torvalds@...ux-foundation.org>, David Woodhouse <dwmw2@...radead.org>, Andrew Morton <akpm@...ux-foundation.org>, LKML <linux-kernel@...r.kernel.org>, "Koskinen Aaro (Nokia-D/Helsinki)" <aaro.koskinen@...ia.com>, Alan Cox <alan@...rguk.ukuu.org.uk> Subject: Re: [PATCH v11 4/5] core: Add kernel message dumper to call on oopses and panics On Fri, 2009-10-16 at 14:09 +0200, Simon Kagstrom wrote: > The core functionality is implemented as per Linus suggestion from > > http://lists.infradead.org/pipermail/linux-mtd/2009-October/027620.html > > (with the kmsg_dump implementation by Linus). A struct kmsg_dumper has > been added which contains a callback to dump the kernel log buffers on > crashes. The kmsg_dump function gets called from oops_exit() and panic() > and invokes this callbacks with the crash reason. > > Signed-off-by: Simon Kagstrom <simon.kagstrom@...insight.net> > Reviewed-by: Anders Grafstrom <anders.grafstrom@...insight.net> > Reviewed-by: Ingo Molnar <mingo@...e.hu> > --- > The bikeshed paint is drying: > > ChangeLog: > * (Ingo Molnar): Flatten lock use > * (Artem, Aaro): Fix style issues > > include/linux/kmsg_dump.h | 44 ++++++++++++++++++ > kernel/panic.c | 3 + > kernel/printk.c | 112 +++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 159 insertions(+), 0 deletions(-) > create mode 100644 include/linux/kmsg_dump.h I wonder, via which tree this should go in. We are going to have mtdoops depend on this. Should we go one of these ways: * this patch goes to one of Ingo's tip trees, so we can pull it and work on top. * we have Ingo's / Linus' acks, and this goes via the MTD tree. ? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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