linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "Chen, Gong" <gong.chen@linux.intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH 2/3] x86, MCE: Avoid potential deadlock in MCE context
Date: Tue, 22 Jul 2014 19:26:09 +0200	[thread overview]
Message-ID: <20140722172609.GI6462@pd.tnic> (raw)
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32871435@ORSMSX114.amr.corp.intel.com>

On Mon, Jul 21, 2014 at 10:03:04PM +0000, Luck, Tony wrote:
> > And drop all the homegrown other stuff like mce_ring and all?
> 
> mce_ring should be easy ... the "mce" structure has the address
> from which we can easily get the pfn to pass into the action-optional
> recovery path.  Only thing missing is a direct indication that this mce
> does contain an AO error that needs to be processed. We could
> re-invoke mce_severity() to figure it out again - or just add a flag
> somewhere.

Right, so if we're going to clean up this mess, I think we should strive
for having a single ring buffer which contains all the MCEs and which we
can iterate over at leisure, either in IRQ context if some of them have
been reported through real exceptions or in process context if they're
simple CEs.

Once they've been eaten by something, we simply remove them from that
buffer and that's it. But sure, one lockless buffer which works in all
contexts would be much better than growing stuff here and there with
different semantics and context usage.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  parent reply	other threads:[~2014-07-22 17:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-16  2:34 Some RAS bug fix patches Chen, Gong
2014-07-16  2:34 ` [PATCH 1/3] APEI, GHES: Cleanup unnecessary function for lock-less list Chen, Gong
2014-07-20  8:01   ` Borislav Petkov
2014-07-16  2:34 ` [RFC PATCH 2/3] x86, MCE: Avoid potential deadlock in MCE context Chen, Gong
2014-07-21  8:47   ` Borislav Petkov
2014-07-21 17:14     ` Luck, Tony
2014-07-21 21:41       ` Borislav Petkov
2014-07-21 22:03         ` Luck, Tony
2014-07-21 22:44           ` [RFC PATCH 2/3] x86, MCE: Avoid potential deadlock in MCE Tony Luck
2014-07-22 17:20             ` Borislav Petkov
2014-07-22 17:26           ` Borislav Petkov [this message]
2014-07-22 21:24             ` [RFC PATCH 2/3] x86, MCE: Avoid potential deadlock in MCE context Tony Luck
2014-07-23  7:48       ` Chen, Gong
2014-07-16  2:34 ` [PATCH 3/3] RAS, HWPOISON: Fix wrong error recovery status Chen, Gong
2014-07-16 19:57   ` Naoya Horiguchi
2014-07-19  8:05 ` Some RAS bug fix patches Chen, Gong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140722172609.GI6462@pd.tnic \
    --to=bp@alien8.de \
    --cc=gong.chen@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox