From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal. Date: Thu, 19 Apr 2018 17:40:06 +0200 Message-ID: <20180419154006.GE3600@pd.tnic> References: <20180416215903.7318-1-mr.nuke.me@gmail.com> <20180416215903.7318-4-mr.nuke.me@gmail.com> <20180418175415.GJ4795@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Alex G." Cc: linux-acpi@vger.kernel.org, linux-edac@vger.kernel.org, rjw@rjwysocki.net, lenb@kernel.org, tony.luck@intel.com, tbaicar@codeaurora.org, will.deacon@arm.com, james.morse@arm.com, shiju.jose@huawei.com, zjzhang@codeaurora.org, gengdongjiu@huawei.com, linux-kernel@vger.kernel.org, alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, devel@acpica.org, mchehab@kernel.org, robert.moore@intel.com, erik.schmauss@intel.com List-Id: linux-acpi@vger.kernel.org On Thu, Apr 19, 2018 at 09:57:07AM -0500, Alex G. wrote: > ghes_severity() is a one-to-one mapping from a set of unsorted > severities to monotonically increasing numbers. The "one-to-one" mapping > part of the sentence is obvious from the function name. To change it to > parse the entire GHES would completely destroy this, and I think it > would apply policy in the wrong place. So do a wrapper or whatever. Do a ghes_compute_severity() or however you would wanna call it and do the iteration there. > Should I do that, I might have to call it something like > ghes_parse_and_apply_policy_to_severity(). But that misses the whole > point if these changes. What policy? You simply compute the severity like we do in the mce code. > I would like to get to the handlers first, and then decide if things are > okay or not, Why? Give me an example why you'd handle an error first and then decide whether we're ok or not? Usually, the error handler decides that in one place. So what exactly are you trying to do differently that doesn't fit that flow? > I don't want to leave people scratching their heads, but I also don't > want to make AER a special case without having a generic way to handle > these cases. People are just as susceptible to scratch their heads > wondering why AER is a special case and everything else crashes. Not if it is properly done *and* documented why we applying the respective policy for the error type. > Maybe it's better move the AER handling to NMI/IRQ context, since > ghes_handle_aer() is only scheduling the real AER andler, and is irq > safe. I'm scratching my head about why we're messing with IRQ work from > NMI context, instead of just scheduling a regular handler to take care > of things. No, first pls explain what exactly you're trying to do and then we can talk about how to do it. Btw, a real-life example to accompany that intention goes a long way. Thx. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: [RFC,v2,3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal. From: Borislav Petkov Message-Id: <20180419154006.GE3600@pd.tnic> Date: Thu, 19 Apr 2018 17:40:06 +0200 To: "Alex G." Cc: linux-acpi@vger.kernel.org, linux-edac@vger.kernel.org, rjw@rjwysocki.net, lenb@kernel.org, tony.luck@intel.com, tbaicar@codeaurora.org, will.deacon@arm.com, james.morse@arm.com, shiju.jose@huawei.com, zjzhang@codeaurora.org, gengdongjiu@huawei.com, linux-kernel@vger.kernel.org, alex_gagniuc@dellteam.com, austin_bolen@dell.com, shyam_iyer@dell.com, devel@acpica.org, mchehab@kernel.org, robert.moore@intel.com, erik.schmauss@intel.com List-ID: T24gVGh1LCBBcHIgMTksIDIwMTggYXQgMDk6NTc6MDdBTSAtMDUwMCwgQWxleCBHLiB3cm90ZToK PiBnaGVzX3NldmVyaXR5KCkgaXMgYSBvbmUtdG8tb25lIG1hcHBpbmcgZnJvbSBhIHNldCBvZiB1 bnNvcnRlZAo+IHNldmVyaXRpZXMgdG8gbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIG51bWJlcnMu IFRoZSAib25lLXRvLW9uZSIgbWFwcGluZwo+IHBhcnQgb2YgdGhlIHNlbnRlbmNlIGlzIG9idmlv dXMgZnJvbSB0aGUgZnVuY3Rpb24gbmFtZS4gVG8gY2hhbmdlIGl0IHRvCj4gcGFyc2UgdGhlIGVu dGlyZSBHSEVTIHdvdWxkIGNvbXBsZXRlbHkgZGVzdHJveSB0aGlzLCBhbmQgSSB0aGluayBpdAo+ IHdvdWxkIGFwcGx5IHBvbGljeSBpbiB0aGUgd3JvbmcgcGxhY2UuCgpTbyBkbyBhIHdyYXBwZXIg b3Igd2hhdGV2ZXIuIERvIGEgZ2hlc19jb21wdXRlX3NldmVyaXR5KCkgb3IgaG93ZXZlciB5b3UK d291bGQgd2FubmEgY2FsbCBpdCBhbmQgZG8gdGhlIGl0ZXJhdGlvbiB0aGVyZS4KCj4gU2hvdWxk IEkgZG8gdGhhdCwgSSBtaWdodCBoYXZlIHRvIGNhbGwgaXQgc29tZXRoaW5nIGxpa2UKPiBnaGVz X3BhcnNlX2FuZF9hcHBseV9wb2xpY3lfdG9fc2V2ZXJpdHkoKS4gQnV0IHRoYXQgbWlzc2VzIHRo ZSB3aG9sZQo+IHBvaW50IGlmIHRoZXNlIGNoYW5nZXMuCgpXaGF0IHBvbGljeT8gWW91IHNpbXBs eSBjb21wdXRlIHRoZSBzZXZlcml0eSBsaWtlIHdlIGRvIGluIHRoZSBtY2UgY29kZS4KCj4gSSB3 b3VsZCBsaWtlIHRvIGdldCB0byB0aGUgaGFuZGxlcnMgZmlyc3QsIGFuZCB0aGVuIGRlY2lkZSBp ZiB0aGluZ3MgYXJlCj4gb2theSBvciBub3QsCgpXaHk/IEdpdmUgbWUgYW4gZXhhbXBsZSB3aHkg eW91J2QgaGFuZGxlIGFuIGVycm9yIGZpcnN0IGFuZCB0aGVuIGRlY2lkZQp3aGV0aGVyIHdlJ3Jl IG9rIG9yIG5vdD8KClVzdWFsbHksIHRoZSBlcnJvciBoYW5kbGVyIGRlY2lkZXMgdGhhdCBpbiBv bmUgcGxhY2UuIFNvIHdoYXQgZXhhY3RseQphcmUgeW91IHRyeWluZyB0byBkbyBkaWZmZXJlbnRs eSB0aGF0IGRvZXNuJ3QgZml0IHRoYXQgZmxvdz8KCj4gSSBkb24ndCB3YW50IHRvIGxlYXZlIHBl b3BsZSBzY3JhdGNoaW5nIHRoZWlyIGhlYWRzLCBidXQgSSBhbHNvIGRvbid0Cj4gd2FudCB0byBt YWtlIEFFUiBhIHNwZWNpYWwgY2FzZSB3aXRob3V0IGhhdmluZyBhIGdlbmVyaWMgd2F5IHRvIGhh bmRsZQo+IHRoZXNlIGNhc2VzLiBQZW9wbGUgYXJlIGp1c3QgYXMgc3VzY2VwdGlibGUgdG8gc2Ny YXRjaCB0aGVpciBoZWFkcwo+IHdvbmRlcmluZyB3aHkgQUVSIGlzIGEgc3BlY2lhbCBjYXNlIGFu ZCBldmVyeXRoaW5nIGVsc2UgY3Jhc2hlcy4KCk5vdCBpZiBpdCBpcyBwcm9wZXJseSBkb25lICph bmQqIGRvY3VtZW50ZWQgd2h5IHdlIGFwcGx5aW5nIHRoZQpyZXNwZWN0aXZlIHBvbGljeSBmb3Ig dGhlIGVycm9yIHR5cGUuCgo+IE1heWJlIGl0J3MgYmV0dGVyIG1vdmUgdGhlIEFFUiBoYW5kbGlu ZyB0byBOTUkvSVJRIGNvbnRleHQsIHNpbmNlCj4gZ2hlc19oYW5kbGVfYWVyKCkgaXMgb25seSBz Y2hlZHVsaW5nIHRoZSByZWFsIEFFUiBhbmRsZXIsIGFuZCBpcyBpcnEKPiBzYWZlLiBJJ20gc2Ny YXRjaGluZyBteSBoZWFkIGFib3V0IHdoeSB3ZSdyZSBtZXNzaW5nIHdpdGggSVJRIHdvcmsgZnJv bQo+IE5NSSBjb250ZXh0LCBpbnN0ZWFkIG9mIGp1c3Qgc2NoZWR1bGluZyBhIHJlZ3VsYXIgaGFu ZGxlciB0byB0YWtlIGNhcmUKPiBvZiB0aGluZ3MuCgpObywgZmlyc3QgcGxzIGV4cGxhaW4gd2hh dCBleGFjdGx5IHlvdSdyZSB0cnlpbmcgdG8gZG8gYW5kIHRoZW4gd2UgY2FuCnRhbGsgYWJvdXQg aG93IHRvIGRvIGl0LiBCdHcsIGEgcmVhbC1saWZlIGV4YW1wbGUgdG8gYWNjb21wYW55IHRoYXQK aW50ZW50aW9uIGdvZXMgYSBsb25nIHdheS4KClRoeC4K