Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753741AbbHCQjx (ORCPT ); Mon, 3 Aug 2015 12:39:53 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:41972 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751971AbbHCQjv (ORCPT ); Mon, 3 Aug 2015 12:39:51 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Hidehiro Kawai Cc: Vivek Goyal , Andrew Morton , linux-mips@linux-mips.org, Baoquan He , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, HATAYAMA Daisuke , Masami Hiramatsu , Daniel Walker , Ingo Molnar References: <20150724011615.6834.79628.stgit@softrs> <55BF4B1F.9000602@hitachi.com> Date: Mon, 03 Aug 2015 11:33:08 -0500 In-Reply-To: <55BF4B1F.9000602@hitachi.com> (Hidehiro Kawai's message of "Mon, 03 Aug 2015 20:06:07 +0900") Message-ID: <877fpcfi2j.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1/0CTAbIx9SOF8ZHRkIhx6yC9XwH9DSbi8= X-SA-Exim-Connect-IP: 97.119.22.40 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.5 XMGappySubj_01 Very gappy subject * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4921] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa05 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject X-Spam-DCC: XMission; sa05 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Hidehiro Kawai X-Spam-Relay-Country: X-Spam-Timing: total 1055 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 6 (0.6%), b_tie_ro: 5.0 (0.5%), parse: 0.59 (0.1%), extract_message_metadata: 12 (1.1%), get_uri_detail_list: 2.2 (0.2%), tests_pri_-1000: 3.4 (0.3%), tests_pri_-950: 0.99 (0.1%), tests_pri_-900: 0.80 (0.1%), tests_pri_-400: 24 (2.3%), check_bayes: 23 (2.1%), b_tokenize: 5 (0.5%), b_tok_get_all: 6 (0.6%), b_comp_prob: 2.9 (0.3%), b_tok_touch_all: 4.2 (0.4%), b_finish: 2.2 (0.2%), tests_pri_0: 607 (57.6%), tests_pri_500: 398 (37.7%), poll_dns_idle: 390 (36.9%), rewrite_mail: 0.00 (0.0%) Subject: Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2319 Lines: 50 Hidehiro Kawai writes: > Hello Eric and Vivek, > > Do you have any comments? crash_kexec_post_notifiers is a debugging hack to allow people to test if the kmsg_dump works better than kexec. crash_kexec_post_notifiers is not, nor has it ever been a solution for general operation (which is what I perceive this work trying to push). I will not support any work that expands crash_kexec_post_notifiers to be more than it currently is, because people want ``panic hooks'' to run before kexec. That appropach was extensively tested before kexec on panic was implemented in the kernel and every implementation failed. The practical symptom was that everything would work ok in testing but on failures in the real world there would be enough going on in the dying kernel that no crash dump would be taken. kexec on panic on the other hand works a reasonable fraction of the time. I deeply and fundamentally can not support a general purpose hook being called before kexec. In 15 years of practice I have never heard of a case where using a general purpose hook does anything but make kexec on panic undebuggable in practice. A specific hook for a very specific purpose when there is no other way we can consider. If you don't have something that generalises well into a general purpose operation that it makes sense for everyone to call you can always use the world's largest aka you can run code before the new kernel starts that is loaded with kexec_load. If you absolutely must run code in the dying code because you need lots of the kernel infrastructure to work, and it is too hard to code a small little bit of stand-alone assembly, I am sorry for you. Experience shows that will never work when the kernel fails in interesting ways. So no. I don't think there is any point to putting any more effort into the crash_kexec_post_notifiers path because experience has shown over the years that in practice it won't work for anyone, and if the code doesn't work in practice there is no point in developing or implementing it. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/