From: Linus Torvalds <torvalds@linux-foundation.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
akpm@linux-foundation.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linuxppc-dev@ozlabs.org, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] synchronize_irq needs a barrier
Date: Thu, 18 Oct 2007 20:26:45 -0700 (PDT) [thread overview]
Message-ID: <alpine.LFD.0.999.0710182007170.26902@woody.linux-foundation.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0710181941020.26902@woody.linux-foundation.org>
On Thu, 18 Oct 2007, Linus Torvalds wrote:
>
> I *think* it should work with something like
>
> for (;;) {
> smp_rmb();
> if (!spin_is_locked(&desc->lock)) {
> smp_rmb();
> if (!(desc->status & IRQ_INPROGRESS)
> break;
> }
> cpu_relax();
> }
I'm starting to doubt this.
One of the issues is that we still need the smp_mb() in front of the loop
(because we want to serialize the loop with any writes in the caller).
The other issue is that I don't think it's enough that we saw the
descriptor lock unlocked, and then the IRQ_INPROGRESS bit clear. It might
have been unlocked *while* the IRQ was in progress, but the interrupt
handler is now in its last throes, and re-takes the spinlock and clears
the IRQ_INPROGRESS thing. But we're not actually happy until we've seen
the IRQ_INPROGRESS bit clear and the spinlock has been released *again*.
So those two tests should actually be the other way around: we want to see
the IRQ_INPROGRESS bit clear first.
It's all just too damn subtle and clever. Something like this should not
need to be that subtle.
Maybe the rigth thing to do is to not rely on *any* ordering what-so-ever,
and just make the rule be: "if you look at the IRQ_INPROGRESS bit, you'd
better hold the descriptor spinlock", and not have any subtle ordering
issues at all.
But that makes us have a loop with getting/releasing the lock all the
time, and then we get back to horrid issues with cacheline bouncing and
unfairness of cache accesses across cores (ie look at the issues we had
with the runqueue starvation in wait_task_inactive()).
Those were fixed by starting out with the non-locked and totally unsafe
versions, but then having one last "check with lock held, and repeat only
if that says things went south".
See commit fa490cfd15d7ce0900097cc4e60cfd7a76381138 and ponder. Maybe we
should take the same approach here, and do something like
repeat:
/* Optimistic, no-locking loop */
while (desc->status & IRQ_INPROGRESS)
cpu_relax();
/* Ok, that indicated we're done: double-check carefully */
spin_lock_irqsave(&desc->lock, flags);
status = desc->status;
spin_unlock_irqrestore(&desc->lock, flags);
/* Oops, that failed? */
if (status & IRQ_INPROGRESS)
goto repeat;
Hmm?
Linus
next prev parent reply other threads:[~2007-10-19 3:27 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-18 1:25 Benjamin Herrenschmidt
2007-10-18 1:45 ` Andrew Morton
2007-10-18 1:55 ` Benjamin Herrenschmidt
2007-10-18 2:12 ` Linus Torvalds
2007-10-18 2:40 ` Benjamin Herrenschmidt
2007-10-18 2:57 ` Benjamin Herrenschmidt
2007-10-18 14:56 ` Herbert Xu
2007-10-18 22:05 ` Benjamin Herrenschmidt
2007-10-18 22:52 ` Linus Torvalds
2007-10-18 23:17 ` Benjamin Herrenschmidt
2007-10-18 23:39 ` Linus Torvalds
2007-10-18 23:52 ` Benjamin Herrenschmidt
2007-10-19 2:32 ` Herbert Xu
2007-10-19 2:52 ` Nick Piggin
2007-10-19 3:28 ` Herbert Xu
2007-10-19 4:49 ` Nick Piggin
2007-10-19 2:55 ` Linus Torvalds
2007-10-19 3:26 ` Linus Torvalds [this message]
2007-10-19 4:11 ` Benjamin Herrenschmidt
2007-10-19 4:26 ` Benjamin Herrenschmidt
2007-10-19 5:53 ` Herbert Xu
2007-10-19 4:20 ` Herbert Xu
2007-10-19 4:29 ` Benjamin Herrenschmidt
2007-10-19 4:35 ` Benjamin Herrenschmidt
2007-10-19 4:48 ` Herbert Xu
2007-10-19 4:58 ` Benjamin Herrenschmidt
2007-10-21 21:10 ` Benjamin Herrenschmidt
2007-10-23 3:26 ` [IRQ]: Fix synchronize_irq races with IRQ handler Herbert Xu
2007-10-19 5:36 ` [NET]: Fix possible dev_deactivate race condition Herbert Xu
2007-10-19 5:38 ` David Miller
2007-10-19 7:35 ` Peter Zijlstra
2007-10-19 9:29 ` Herbert Xu
2007-10-18 14:35 ` [PATCH] synchronize_irq needs a barrier Herbert Xu
2007-10-18 21:35 ` Benjamin Herrenschmidt
2007-10-20 2:02 ` Maxim Levitsky
2007-10-20 2:25 ` Linus Torvalds
2007-10-20 3:10 ` Maxim Levitsky
2007-10-20 4:06 ` Benjamin Herrenschmidt
2007-10-20 4:04 ` Benjamin Herrenschmidt
2007-10-20 4:09 ` Benjamin Herrenschmidt
2007-10-20 3:37 ` Herbert Xu
2007-10-20 3:56 ` Benjamin Herrenschmidt
2007-10-20 4:24 ` Maxim Levitsky
2007-10-20 5:04 ` Benjamin Herrenschmidt
2007-10-20 5:36 ` Maxim Levitsky
2007-10-20 5:46 ` Benjamin Herrenschmidt
2007-10-20 6:06 ` Maxim Levitsky
2007-10-20 6:13 ` Benjamin Herrenschmidt
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=alpine.LFD.0.999.0710182007170.26902@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®