From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: RE: [PATCH] New CMC/CPE polling
Date: Mon, 04 Aug 2003 20:43:35 +0000 [thread overview]
Message-ID: <marc-linux-ia64-106003003014980@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105969308328993@msgid-missing>
> You might be right on the clearing side, I think moving it down
> a couple lines and disabling local interrupts would eliminate the
> potential hole though. Something like this:
>
> ia64_mca_cmc_int_caller(...)
> {
> ...
> smp_call_function(ia64_mca_cmc_vector_enable, NULL, 1, 0);
> local_irq_disable();
> ia64_mca_cmc_vector_enable(NULL);
> cmc_polling_enabled = 0;
> ...
>
> Does that address the race you were looking at? I don't see one
> on the setting end, could you be more specific? The spinlock feels
> like it does the trick to me. Thanks for the comments,
My issue is that you check and set cmc_polling_enabled under the
protection of a lock (cmc_history_lock ... I realise that this is
mostly protecting the cmc_history[], but it also defends against
multiple cpus taking a CMCI at the same time and all trying to
switch over to polling mode).
But you clear cmc_polling_enabled without the lock. So the race is
between enabling the interrupt (on all cpus) and taking the next
interrupt. The local_irq_disable() in the above fragment fixes that
for the current cpu, but for other cpus you can end up in the handler
with cmc_polling_enabled set to the wrong value.
One way might be harmless, but I'm not sure which.
-Tony
next prev parent reply other threads:[~2003-08-04 20:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-31 23:06 [PATCH] New CMC/CPE polling Alex Williamson
2003-08-01 6:34 ` David Mosberger
2003-08-01 14:20 ` Alex Williamson
2003-08-04 18:26 ` Luck, Tony
2003-08-04 18:49 ` Alex Williamson
2003-08-04 20:43 ` Luck, Tony [this message]
2003-08-04 21:15 ` Alex Williamson
2003-08-04 21:53 ` Luck, Tony
2003-08-04 23:09 ` David Mosberger
2003-08-08 18:39 ` Bjorn Helgaas
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=marc-linux-ia64-106003003014980@msgid-missing \
--to=tony.luck@intel.com \
--cc=linux-ia64@vger.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.