mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®