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: Fri, 4 Feb 2011 10:00:47 -0500 From: Vivek Goyal <vgoyal@...hat.com> To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> Cc: "Eric W. Biederman" <ebiederm@...ssion.com>, linux kernel mailing list <linux-kernel@...r.kernel.org>, Jarod Wilson <jwilson@...hat.com> Subject: Re: Query about kdump_msg hook into crash_kexec() On Thu, Feb 03, 2011 at 02:20:53PM +0900, KOSAKI Motohiro wrote: > > AFAIK, kexec is used sneak rebooting way when the system face unexpected > > scenario on some devices. (Some embedded is running very long time, then > > it can't avoid memory bit corruption. all of reset is a last resort. > > and a vendor gather logs at periodically checkback). > > > > The main purpose of to introduce KMSG_DUMP_KEXEC is to be separate it > > from KMSG_DUMP_PANIC. At kmsg_dump() initial patch, KMSG_DUMP_PANIC > > is always called both kdump is configured or not. But it's no good idea > > the same log is to be appeared when both kexec was successed and failured. > > Moreover someone don't want any log at kexec phase. They only want logs > > when real panic (ie kexec failure) route. Then, I've separated it to two. > > Two separated argument can solve above both requreiment. > > A bit additional explanation, An original patch have kmsg_dump(KMSG_DUMP_PANIC) > callsite at following point. I didn't think it makes either embedded or > kdump folks happiness. Thus I moved it after crash_kexec(). > > > --------------------------------------------------------------------- > @@ -74,6 +75,7 @@ NORET_TYPE void panic(const char * fmt, ...) > dump_stack(); > #endif > > + kmsg_dump(KMSG_DUMP_PANIC); > /* > * If we have crashed and we have a crash kernel loaded let it handle > * everything else. > * Do we want to call this before we try to display a message? > */ > crash_kexec(NULL); > --------------------------------------------------------------------- And I think to compensate for that somebody introduced additional kmsg_dump(KEXEC) call inside crash_kexec() and put it under CONFIG option so that one can change the behavior based on config options. I think this makes the logic somewhat twisted and an unnecessary call inside crash_kexec(). So until and unless there is a strong reason we can get rid of KEXEC event and move kmsg_dump call before crash_kexec() for now and see how does it go, IMHO. Vivek -- 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