From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from out02.mta.xmission.com ([166.70.13.232]) by casper.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1S7ASs-0008H7-9Z for kexec@lists.infradead.org; Mon, 12 Mar 2012 18:59:29 +0000 From: ebiederm@xmission.com (Eric W. Biederman) References: <4F573E1C.2060909@oss.ntt.co.jp> <4F573E74.5040504@oss.ntt.co.jp> <4F58495B.5080308@oss.ntt.co.jp> <4F5A6D87.4050809@zytor.com> <4F5D8D0E.8060702@oss.ntt.co.jp> <4F5D8E63.60606@zytor.com> <4F5D943C.5020403@oss.ntt.co.jp> <20120312133619.GB17288@redhat.com> Date: Mon, 12 Mar 2012 12:02:06 -0700 In-Reply-To: <20120312133619.GB17288@redhat.com> (Vivek Goyal's message of "Mon, 12 Mar 2012 09:36:19 -0400") Message-ID: MIME-Version: 1.0 Subject: Re: [PATCH 1/2] boot: ignore early NMIs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Vivek Goyal Cc: Don Zickus , akpm@linux-foundation.org, linux-tip-commits@vger.kernel.org, Yinghai Lu , Fernando Luis =?utf-8?Q?V=C3=A1zquez?= Cao , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, mingo@redhat.com, "H. Peter Anvin" , tglx@linutronix.de, torvalds@linux-foundation.org, mingo@elte.hu Vml2ZWsgR295YWwgPHZnb3lhbEByZWRoYXQuY29tPiB3cml0ZXM6Cgo+IE9uIE1vbiwgTWFyIDEy LCAyMDEyIGF0IDAzOjE0OjIwUE0gKzA5MDAsIEZlcm5hbmRvIEx1aXMgVsOhenF1ZXogQ2FvIHdy b3RlOgo+Cj4gWy4uXQo+PiBUaGUgdGhpbmcgaXMgdGhhdCB3ZSB3YW50IHRvIGF2b2lkIHBsYXlp bmcgd2l0aCBoYXJkd2FyZSBpbiB0aGUga2R1bXAKPj4gcmVib290IHBhdGNoIHdoZW4gd2UgY2Fu IGF2b2lkIGl0LCB0aGUgcHJlbWlzZSBiZWluZyB0aGF0IGl0IGNhbm5vdAo+PiBiZSBhY2Nlc3Nl ZCB3aXRob3V0IHJpc2tpbmcgYSBsb2NrdXAgb3Igd29yc2UgKGFzIHRoZSBkZWFkbG9jayBhY2Nl c3NpbmcKPj4gdGhlIEkvTyBBUElDIHNob3dlZCkuCj4KPiBJIHRoaW5rIHRoZXJlIG5lZWRzIHRv IGJlIGEgbGltaXQgdG8gYmVpbmcgcGFyYW5vaWQuIE9uIG9uZSBoYW5kIHBlb3BsZQo+IHdhbnQg dG8gcnVuIHBhbmljIG5vdGlmaWVycywgYWxsIHRoZSBrbXNnX2R1bXAoKSBob29rcyBpbiBwYW5p YyBwYXRoLCBhbmQKPiBvbiB0aGUgb3RoZXIgaGFuZCB3ZSBhcmUgYWZyYWlkIG9mIGV2ZW4gZGlz YWJsaW5nIExBUElDLgoKQW5kIHRoZSBrbXNnX2R1bXAgY29kZSBhbmQgdGhlIHBhbmljIG5vdGlm aWVycyBhcmVuJ3QgYmVpbmcgcnVuLiAgSGF2aW5nCnNlZW4gc29tZSBvZiB0aGVpciBmYWlsdXJl IG1vZGVzIGJlaW5nIHBhdGNoZWQgdXAgcmVjZW50bHkgKEFkZGluZyBhbmQKcmVtb3Zpbmcgc3lz ZnMgZmlsZXMhISEhKSBJJ20gdmVyeSBjb21mb3J0YWJsZSB3aXRoIHRoZSBsZXZlbCBvZgpwYXJh bm9pYS4KCkl0IGhhcyBiZWVuIHByb3ZlbiB0aW1lIGFuZCB0aW1lIGFnYWluIHRoYXQgdGhlIG1v cmUgeW91IGRvIGluIHRoZQpmYWlsaW5nIGtlcm5lbCB0aGF0IHRoZSBncmVhdGVyIHlvdXIgbGlr ZWx5LWhvb2Qgb2Ygbm90IGdldHRpbmcgeW91cgpmYWlsdXJlIGluZm9ybWF0aW9uIG91dC4KCj4g SSBwZXJzb25hbGx5IHRoaW5rIHRoYXQgZGlzYWJsaW5nIExBUElDIGlzIHJlYXNvbmFibHkgcHJh Y3RpY2FsIHNvbHV0aW9uCj4gdG8gdGhlIHByb2JsZW0gdW50aWwgYW5kIHVubGVzcyBzb21lYm9k eSBzaG93cyB0aGF0IGl0IGRlYWRsb2Nrcwo+IGVhc2lseS4KCkRpc2FibGluZyBOTUkgZ2VuZXJh dGlvbiBpbiB0aGUgTEFQSUMgaXMgZmluZSwgYW5kIGZvciB0aGUgc2hvcnQgdGVybQpJIGRvbid0 IGV2ZW4gaGF2ZSBhIHByb2JsZW0gd2l0aCBkaXNhYmxpbmcgdGhlIGVudGlyZSBMQVBJQyBhcyBh bGwgb2YKb3VyIHBsYXRmb3JtcyBzZWVtIHRvIGhhdmUgY29kZSBmb3IgY29tcGxldGVseSByZXBy b2dyYW1taW5nIGl0LgoKQXQgdGhlIHNhbWUgdGltZSB0aGVyZSBoYXZlIGJlZW4gY2FzZXMgbGlr ZSB0aGUgaTgyNTkgcm91dGVkIHRocm91Z2gKdGhlIEV4dEludCBwaW4gb2YgdGhlIGxhcGNpIHRo YXQgd2UgaGF2ZW4ndCBiZWVuIGdpdmVuIHByb2dyYW1taW5nCmluZm9ybWF0aW9uIGFib3V0IGFu ZCB0aGF0IGlmIHdlIHdhbnQgdG8gd29yayB3ZSBzaG91bGQgYXZvaWQgdG91Y2hpbmcuCgpGdXJ0 aGVybW9yZSB3ZSBoYXZlIHR3byByZXBvcnRlZCBjYXNlcyBvZiBwZW9wbGUgZXhwZXJpZW5jaW5n IHJlYWwgTk1JcwpvbiB0aGUga2R1bXAgcGF0aC4gIFNvIHdlIGhhdmUgdG8gYXNzdW1lIHRoZSBw cmVzZW5jZSBvZiB0aGUgQ01PUyBubWkKZGlzYWJsZSBhcyB3ZWxsIGlmIHdlIGFyZSBnb2luZyB0 byB1bmVxdWl2b2NhbGx5IGRpc2FibGUgTk1Jcy4KCkdpdmVuIHRoZSB2YXJpZXR5IG9mIHg4NiBo YXJkd2FyZSB0b2RheSBhbmQgdGhlIGdyb3dpbmcgdmFyaWV0eSBvZiB4ODYKaGFyZHdhcmUgdG9t b3Jyb3cgd2UgYXJlIGdvaW5nIHRvIGJlIGZpeGluZyB0aGlzIHVudGlsIHdlIGNhbiBhY3R1YWxs eQpoYW5kbGUgdGhlIE5NSXMuICBIYXJkd2FyZSBkZXNpZ25lcnMgYXJlIHVuZm9ydHVuYXRlbHkg Y3JlYXRpdmUgZW5vdWdoCnRoYXQgd2UgYXJlbid0IGdvaW5nIHRvIHRoaW5rIG9mIGV2ZXJ5dGhp bmcuICBHaXZlbiB0aGF0IGl0IGlzIGhhcyB0YWtlbgp1cyBhbG1vc3QgYSBkZWNhZGUgdG8gcmVh bGl6ZSB0aGF0IHRoZXJlIGFjdHVhbGx5IGlzIGEgcmVhbCB3b3JsZApwcm9ibGVtICBJJ20gbm90 IHRvbyBrZWVuIG9uIGEgc29sdXRpb24gdGhhdCBpcyBqdXN0IGdvb2QgZW5vdWdoIHRvCmZpeCBh IHNtYWxsIHByb2JsZW0uCgpJIHdvdWxkIGxvdmUgaXQgaWYgeDg2IGhhZCBhbiBhcmNoaXRlY3R1 cmFsIE5NSSBvZmYgc3dpdGNoIGJ1dCB3aXRoCkludGVsIHB1c2hpbmcgRUZJIGFuZCB0aGUgcmVt b3ZhbCBvZiB0aGUgY21vcyBjbG9jayB4ODYgbm8gbG9uZ2VyCmhhcyBhbiBhbHdheXMgYXZhaWxh YmxlIE5NSSBvZmYgc3dpdGNoLgoKRnVydGhlcm1vcmUgaGFuZGxpbmcgb2YgTk1JIGlzIG5vdCBo YXJkIGl0IGlzIGp1c3QgYSBsaXR0bGUgdHJpY2t5LAp0byB0ZXN0LgoKRXJpYwoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Ka2V4ZWMgbWFpbGluZyBsaXN0 CmtleGVjQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcvbWFp bG1hbi9saXN0aW5mby9rZXhlYwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756577Ab2CLS6w (ORCPT ); Mon, 12 Mar 2012 14:58:52 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:51755 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756536Ab2CLS6u convert rfc822-to-8bit (ORCPT ); Mon, 12 Mar 2012 14:58:50 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Vivek Goyal Cc: Fernando Luis =?utf-8?Q?V=C3=A1zquez?= Cao , "H. Peter Anvin" , Don Zickus , linux-tip-commits@vger.kernel.org, torvalds@linux-foundation.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, mingo@elte.hu, Yinghai Lu , akpm@linux-foundation.org References: <4F573E1C.2060909@oss.ntt.co.jp> <4F573E74.5040504@oss.ntt.co.jp> <4F58495B.5080308@oss.ntt.co.jp> <4F5A6D87.4050809@zytor.com> <4F5D8D0E.8060702@oss.ntt.co.jp> <4F5D8E63.60606@zytor.com> <4F5D943C.5020403@oss.ntt.co.jp> <20120312133619.GB17288@redhat.com> Date: Mon, 12 Mar 2012 12:02:06 -0700 In-Reply-To: <20120312133619.GB17288@redhat.com> (Vivek Goyal's message of "Mon, 12 Mar 2012 09:36:19 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=;;;mid=;;;hst=in01.mta.xmission.com;;;ip=98.207.153.68;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18JSB3MG1iSqZ4Dm9s8O91E9QCdWWS9UlI= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * 1.2 SARE_LWSHORTT BODY: SARE_LWSHORTT * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.4 UNTRUSTED_Relay Comes from a non-trusted relay X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Vivek Goyal X-Spam-Relay-Country: ** Subject: Re: [PATCH 1/2] boot: ignore early NMIs X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -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 Vivek Goyal writes: > On Mon, Mar 12, 2012 at 03:14:20PM +0900, Fernando Luis Vázquez Cao wrote: > > [..] >> The thing is that we want to avoid playing with hardware in the kdump >> reboot patch when we can avoid it, the premise being that it cannot >> be accessed without risking a lockup or worse (as the deadlock accessing >> the I/O APIC showed). > > I think there needs to be a limit to being paranoid. On one hand people > want to run panic notifiers, all the kmsg_dump() hooks in panic path, and > on the other hand we are afraid of even disabling LAPIC. And the kmsg_dump code and the panic notifiers aren't being run. Having seen some of their failure modes being patched up recently (Adding and removing sysfs files!!!!) I'm very comfortable with the level of paranoia. It has been proven time and time again that the more you do in the failing kernel that the greater your likely-hood of not getting your failure information out. > I personally think that disabling LAPIC is reasonably practical solution > to the problem until and unless somebody shows that it deadlocks > easily. Disabling NMI generation in the LAPIC is fine, and for the short term I don't even have a problem with disabling the entire LAPIC as all of our platforms seem to have code for completely reprogramming it. At the same time there have been cases like the i8259 routed through the ExtInt pin of the lapci that we haven't been given programming information about and that if we want to work we should avoid touching. Furthermore we have two reported cases of people experiencing real NMIs on the kdump path. So we have to assume the presence of the CMOS nmi disable as well if we are going to unequivocally disable NMIs. Given the variety of x86 hardware today and the growing variety of x86 hardware tomorrow we are going to be fixing this until we can actually handle the NMIs. Hardware designers are unfortunately creative enough that we aren't going to think of everything. Given that it is has taken us almost a decade to realize that there actually is a real world problem I'm not too keen on a solution that is just good enough to fix a small problem. I would love it if x86 had an architectural NMI off switch but with Intel pushing EFI and the removal of the cmos clock x86 no longer has an always available NMI off switch. Furthermore handling of NMI is not hard it is just a little tricky, to test. Eric