From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Don Zickus <dzickus@redhat.com>, Jan Kiszka <jan.kiszka@web.de>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Eric Paris <eparis@redhat.com>,
Randy Dunlap <randy.dunlap@oracle.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: BUG: using smp_processor_id() in preemptible arch_trigger_all_cpu_backtrace_handler
Date: Fri, 5 Nov 2010 19:37:51 +0300 [thread overview]
Message-ID: <20101105163751.GA5678@lenovo> (raw)
In-Reply-To: <AANLkTikVSpw-R6Jt-ZfK6sJXoRv7wJ7-vPHQGcNYkVDK@mail.gmail.com>
On Fri, Nov 05, 2010 at 05:06:55PM +0100, Frederic Weisbecker wrote:
> 2010/11/1 Cyrill Gorcunov <gorcunov@gmail.com>:
...
> > yup, this will do the trick for a while. In general I believe we might have
> > kind of NMI exclusive chain so we wouldn't need the 'case:'s.
>
> Yeah. And seperating NMIs from the rest of the DIE notifiers would
> probably improve
> performance of things like PMI handling.
>
It will make it more straight and clean as minimum which is already
quite a benefit ;) There were patches floating from Don with notify
priorities which are good start. Though I didn't manage to look into
most of patches I've been CC'ed yet :(
> And I've always been confused with this "die" notifier semantic. We
> are not dying when
> we handle a counter overflow interrupt.
> The same applies to DIE_INT3, DIE_TRAP, DIE_DEBUG, ....
>
As the comment says on top of the enum they are "Grossly misnamed" ;)
Though we could consider them not as "dying" but rather in terms of say
on-die signals (or something like that).
> But until then, as having a seperate notifier is quite a refactoring,
> we should enqueue Don's fix.
> Don, can you resend it with usual SOB and changelog?
>
> Thanks.
>
Cyrill
prev parent reply other threads:[~2010-11-05 16:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-01 12:39 BUG: using smp_processor_id() in preemptible arch_trigger_all_cpu_backtrace_handler Jan Kiszka
2010-11-01 15:37 ` Cyrill Gorcunov
2010-11-01 15:45 ` Don Zickus
2010-11-01 15:51 ` Cyrill Gorcunov
2010-11-05 16:06 ` Frederic Weisbecker
2010-11-05 16:37 ` Cyrill Gorcunov [this message]
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=20101105163751.GA5678@lenovo \
--to=gorcunov@gmail.com \
--cc=dzickus@redhat.com \
--cc=eparis@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jan.kiszka@web.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=randy.dunlap@oracle.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 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.