From: Borislav Petkov <bp@amd64.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Ingo Molnar <mingo@elte.hu>, Borislav Petkov <bp@amd64.org>,
Peter Zijlstra <peterz@infradead.org>,
Huang Ying <ying.huang@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <petkovbb@googlemail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mauro@elte.hu" <mauro@elte.hu>
Subject: Re: [RFC][PATCH] irq_work
Date: Thu, 24 Jun 2010 17:41:24 +0200 [thread overview]
Message-ID: <20100624154124.GA6647@aftab> (raw)
In-Reply-To: <20100624140143.GO578@basil.fritz.box>
From: Andi Kleen <andi@firstfloor.org>
Date: Thu, Jun 24, 2010 at 10:01:43AM -0400
> > Please, as Peter and Boris asked you already, quote a concrete, specific
> > example:
>
> It was already in my answer to Peter.
>
> >
> > 'Specific event X occurs, kernel wants/needs to do Y. This cannot be done
> > via the suggested method due to Z.'
> >
> > Your generic arguments look wrong (to the extent they are specified) and it
> > makes it much easier and faster to address your points if you dont blur them
> > by vagaries.
>
> It's one of the fundamental properties of recoverable errors.
>
> Error happens.
> Machine check or NMI or other exception happens.
> That exception runs on the exception stack
> The error is not fatal, but recoverable.
> For example you want to kill a process or call hwpoison or do some other
> recovery action. These generally have to sleep to do anything
> interesting.
> You cannot do the sleeping on the exception stack, so you push it to
> another context.
>
> Now just because an error is recoverable doesn't mean it's not critical
> (I think that was the mistake Boris made).
It wasn't a mistake - I was simply trying to lure you into giving a more
concrete example so that we all land on the same page and we know what
the heck you/we/all are talking about.
> If you don't do something
> (like killing or recovery) you could end up in a loop or consume
> corrupted data or something else bad.
>
> So the error has to have a fail safe path from detection to handling.
So we are talking about a more involved and "could-sleep" error
recovery.
> That's quite different from logging or performance counting etc.
> where dropping events on overload is normal and expected.
So I went back and reread the whole thread, and correct me if I'm
wrong but the whole run softirq after NMI has one use case for now -
"could-sleep" error handling for MCEs _only_ on x86. So you're changing
a bunch of generic and x86 kernel code just for error handling. Hmm,
that's a kinda big hammer in my book.
A slimmer solution is a much better way to go, IMHO. I think Peter said
something about irq_exit(), which should be just fine.
But AFAICT an arch-specific solution would be even better, e.g.
if you call into your deferred work helper from paranoid_exit in
<arch/x86/kernel/entry_64.S>. I.e, something like
#ifdef CONFIG_X86_MCE
testl $_TIF_NEED_POST_NMI,%ebx
jnz do_post_nmi_work
#endif
Or even slimmer, rewrite the paranoidzeroentry to a MCE-specific variant
which does the added functionality. But that wouldn't be extensible if
other entities want post-NMI work later.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2010-06-24 15:39 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-24 3:04 [RFC 1/5] Make soft_irq NMI safe Huang Ying
2010-06-24 3:04 ` [RFC 2/5] NMI return notifier Huang Ying
2010-06-24 3:04 ` [RFC 3/5] x86, trigger NMI return notifier soft_irq earlier Huang Ying
2010-06-24 6:03 ` Peter Zijlstra
2010-06-24 3:04 ` [RFC 4/5] x86, Use NMI return notifier in MCE Huang Ying
2010-06-24 10:00 ` Andi Kleen
2010-06-24 3:04 ` [RFC 5/5] Use NMI return notifier in perf pending Huang Ying
2010-06-24 6:00 ` Peter Zijlstra
2010-06-24 6:09 ` [RFC 1/5] Make soft_irq NMI safe Peter Zijlstra
2010-06-24 6:45 ` Huang Ying
2010-06-24 6:35 ` [RFC][PATCH] irq_work Peter Zijlstra
2010-06-24 6:43 ` Huang Ying
2010-06-24 6:47 ` Peter Zijlstra
2010-06-24 6:50 ` Huang Ying
2010-06-24 6:58 ` Peter Zijlstra
2010-06-24 7:04 ` Huang Ying
2010-06-24 7:19 ` Peter Zijlstra
2010-06-24 7:27 ` Huang Ying
2010-06-24 7:32 ` Peter Zijlstra
2010-06-24 10:27 ` Andi Kleen
2010-06-24 10:30 ` Peter Zijlstra
2010-06-24 10:52 ` Andi Kleen
2010-06-24 10:58 ` Peter Zijlstra
2010-06-24 11:08 ` Andi Kleen
2010-06-24 11:10 ` Peter Zijlstra
2010-06-24 11:20 ` Andi Kleen
2010-06-24 11:33 ` Peter Zijlstra
2010-06-24 11:55 ` Andi Kleen
2010-06-24 11:57 ` Peter Zijlstra
2010-06-24 12:02 ` Andi Kleen
2010-06-24 12:18 ` Peter Zijlstra
2010-06-24 12:38 ` Andi Kleen
2010-06-25 10:38 ` Peter Zijlstra
2010-06-24 11:42 ` Peter Zijlstra
2010-06-24 11:58 ` Andi Kleen
2010-06-24 12:02 ` Peter Zijlstra
2010-06-24 11:23 ` Ingo Molnar
2010-06-24 11:34 ` Peter Zijlstra
2010-06-24 12:35 ` Ingo Molnar
2010-06-24 13:02 ` Andi Kleen
2010-06-24 13:20 ` Borislav Petkov
2010-06-24 13:33 ` Andi Kleen
2010-06-24 13:42 ` Ingo Molnar
2010-06-24 13:46 ` Ingo Molnar
2010-06-24 14:01 ` Andi Kleen
2010-06-24 15:41 ` Borislav Petkov [this message]
2010-06-24 16:09 ` Andi Kleen
2010-06-25 2:12 ` Huang Ying
2010-06-25 7:48 ` Peter Zijlstra
2010-06-25 9:17 ` Huang Ying
2010-06-25 9:23 ` Frederic Weisbecker
2010-06-25 9:30 ` Huang Ying
2010-06-25 9:44 ` Frederic Weisbecker
2010-06-25 9:30 ` Peter Zijlstra
2010-06-25 11:58 ` huang ying
2010-06-25 9:08 ` Andi Kleen
2010-06-25 18:30 ` [RFC][PATCH] irq_work -v2 Peter Zijlstra
2010-06-25 19:30 ` Andi Kleen
2010-06-25 19:39 ` Peter Zijlstra
2010-06-25 19:49 ` Peter Zijlstra
2010-06-25 22:29 ` Andi Kleen
2010-06-26 8:36 ` Peter Zijlstra
2010-06-26 10:08 ` Andi Kleen
2010-06-26 10:32 ` Peter Zijlstra
2010-06-25 19:47 ` Peter Zijlstra
2010-06-26 1:26 ` huang ying
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=20100624154124.GA6647@aftab \
--to=bp@amd64.org \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mauro@elte.hu \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=petkovbb@googlemail.com \
--cc=ying.huang@intel.com \
/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;
as well as URLs for NNTP newsgroup(s).