All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'
Date: Thu, 13 Apr 2017 00:16:39 +0200	[thread overview]
Message-ID: <20170412221639.5klmqk4mjbvy6btx@pd.tnic> (raw)
In-Reply-To: <20170412214749.jyt7cmyhovivtb2m@pd.tnic>

On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote:
> so we need to think about something better to handle events down the
> whole chain. Maybe route events from the atomic path to the blocking
> path where the sleeping notifier callbacks can sleep as much as they
> want to...

... and it is midnight here so I could be talking crap but we probably
should really split the reporting "chain" into two:

1. atomic context which doesn't do any notifier wankery. We simply call
non-sleeping functions one after the other. And those should be fast and
not taking any locks.

For example, I'm thinking you want to decode the error and that's it. So
we can replace the notifier call in print_mce() with our atomic context
function.

Then:

2. move the notifier completely in process context, convert it to a
blocking one and connect there all the noodling stuff like EDAC, NFIT,
mcelog, EXTLOG, ... I.e., all the logging machinery.

Problem solved.

And here's where you come in and say, "Boris, you're talking crap.." :-)

Lemme sleep on it.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@suse.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Dan Williams <dan.j.williams@intel.com>,
	"Verma, Vishal L" <vishal.l.verma@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@ml01.01.org>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'
Date: Thu, 13 Apr 2017 00:16:39 +0200	[thread overview]
Message-ID: <20170412221639.5klmqk4mjbvy6btx@pd.tnic> (raw)
In-Reply-To: <20170412214749.jyt7cmyhovivtb2m@pd.tnic>

On Wed, Apr 12, 2017 at 11:47:49PM +0200, Borislav Petkov wrote:
> so we need to think about something better to handle events down the
> whole chain. Maybe route events from the atomic path to the blocking
> path where the sleeping notifier callbacks can sleep as much as they
> want to...

... and it is midnight here so I could be talking crap but we probably
should really split the reporting "chain" into two:

1. atomic context which doesn't do any notifier wankery. We simply call
non-sleeping functions one after the other. And those should be fast and
not taking any locks.

For example, I'm thinking you want to decode the error and that's it. So
we can replace the notifier call in print_mce() with our atomic context
function.

Then:

2. move the notifier completely in process context, convert it to a
blocking one and connect there all the noodling stuff like EDAC, NFIT,
mcelog, EXTLOG, ... I.e., all the logging machinery.

Problem solved.

And here's where you come in and say, "Boris, you're talking crap.." :-)

Lemme sleep on it.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

  reply	other threads:[~2017-04-12 22:16 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-11 22:44 [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic' Vishal Verma
2017-04-11 22:44 ` Vishal Verma
2017-04-12  9:14 ` Borislav Petkov
2017-04-12  9:14   ` Borislav Petkov
2017-04-12 19:59   ` Vishal Verma
2017-04-12 19:59     ` Vishal Verma
2017-04-12 20:22     ` Borislav Petkov
2017-04-12 20:22       ` Borislav Petkov
2017-04-12 20:27       ` Verma, Vishal L
2017-04-12 20:27         ` Verma, Vishal L
2017-04-12 20:52         ` Luck, Tony
2017-04-12 20:52           ` Luck, Tony
2017-04-12 20:55           ` Dan Williams
2017-04-12 20:55             ` Dan Williams
2017-04-12 21:12             ` Thomas Gleixner
2017-04-12 21:12               ` Thomas Gleixner
2017-04-12 21:19               ` Luck, Tony
2017-04-12 21:19                 ` Luck, Tony
2017-04-12 21:47                 ` Borislav Petkov
2017-04-12 21:47                   ` Borislav Petkov
2017-04-12 22:16                   ` Borislav Petkov [this message]
2017-04-12 22:16                     ` Borislav Petkov
2017-04-12 22:26                     ` Luck, Tony
2017-04-12 22:26                       ` Luck, Tony
2017-04-12 22:29                       ` Borislav Petkov
2017-04-12 22:29                         ` Borislav Petkov
2017-04-13 11:31                         ` Borislav Petkov
2017-04-13 11:31                           ` Borislav Petkov
2017-04-13 12:12                           ` Borislav Petkov
2017-04-13 12:12                             ` Borislav Petkov
2017-04-18 16:28                             ` Luck, Tony
2017-04-18 16:28                               ` Luck, Tony
     [not found]                           ` <20170413113159.rc32ebiswn64nzrr-fF5Pk5pvG8Y@public.gmane.org>
2017-04-21 21:39                             ` Verma, Vishal L
2017-04-21 21:39                               ` Verma, Vishal L
2017-04-12 21:13         ` Borislav Petkov
2017-04-12 21:13           ` Borislav Petkov
2017-04-12 21:50           ` Thomas Gleixner
2017-04-12 21:50             ` Thomas Gleixner
2017-04-12 22:42             ` Paul E. McKenney
2017-04-12 22:42               ` Paul E. McKenney
2017-04-12 23:45               ` Paul E. McKenney
2017-04-12 23:45                 ` Paul E. McKenney
2017-04-13 14:34                 ` Paul E. McKenney
2017-04-13 14:34                   ` Paul E. McKenney
2017-04-18 20:27 ` [tip:ras/urgent] x86/mce: Make the MCE notifier a blocking one tip-bot for Vishal Verma
2017-04-18 20:27   ` tip-bot for Borislav Petkov

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=20170412221639.5klmqk4mjbvy6btx@pd.tnic \
    --to=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@ml01.01.org \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.