All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: benh@kernel.crashing.org
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	akpm <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] synchronize_irq needs a barrier
Date: Sat, 20 Oct 2007 04:02:42 +0200	[thread overview]
Message-ID: <200710200402.43106.maximlevitsky@gmail.com> (raw)
In-Reply-To: <1192670742.12879.5.camel@pasglop>

On Thursday 18 October 2007 03:25:42 Benjamin Herrenschmidt wrote:
> synchronize_irq needs at the very least a compiler barrier and a
> read barrier on SMP, but there are enough cases around where a
> write barrier is also needed and it's not a hot path so I prefer
> using a full smp_mb() here.
> 
> It will degrade to a compiler barrier on !SMP.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> 
> Index: linux-work/kernel/irq/manage.c
> ===================================================================
> --- linux-work.orig/kernel/irq/manage.c	2007-10-18 11:22:16.000000000 +1000
> +++ linux-work/kernel/irq/manage.c	2007-10-18 11:22:20.000000000 +1000
> @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq)
>  	if (irq >= NR_IRQS)
>  		return;
>  
> +	smp_mb();
>  	while (desc->status & IRQ_INPROGRESS)
>  		cpu_relax();
>  }
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,

I have read this thread and I concluded few things:

1) It is impossible to know that the card won't send more interrupts:
Even if I do a read from the device, the IRQ can be pending in the bus/APIC
It is even possible (and likely) that the IRQ line will be shared, thus the 
handler can be called by non-relevant device.

2) the synchronize_irq(); in .suspend is useless:
an IRQ can happen immediately after this synchronize_irq();
and interrupt even the .suspend()
(At least theoretically)


Thus I now understand that .suspend() should do:

	saa_writel(SAA7134_IRQ1, 0);
	saa_writel(SAA7134_IRQ2, 0);
	saa_writel(SAA7134_MAIN_CTRL, 0);

	dev->insuspend = 1;
	smp_wmb();

	/* at that point the _request to disable card's IRQs was issued, we don't know 
	   that there will be no irqs anymore.
	   the smp_mb(); guaranties that the IRQ handler will bail out in that case. */
	
	/* .......*/

	pci_save_state(pci_dev);
	pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
	return 0;

and the interrupt handler:

	smp_rmb();
	if (dev->insuspend)
		goto out;

Am I right?
	Best regards,
		Maxim Levitsky

WARNING: multiple messages have this Message-ID (diff)
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: benh@kernel.crashing.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	akpm <akpm@linux-foundation.org>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] synchronize_irq needs a barrier
Date: Sat, 20 Oct 2007 04:02:42 +0200	[thread overview]
Message-ID: <200710200402.43106.maximlevitsky@gmail.com> (raw)
In-Reply-To: <1192670742.12879.5.camel@pasglop>

On Thursday 18 October 2007 03:25:42 Benjamin Herrenschmidt wrote:
> synchronize_irq needs at the very least a compiler barrier and a
> read barrier on SMP, but there are enough cases around where a
> write barrier is also needed and it's not a hot path so I prefer
> using a full smp_mb() here.
> 
> It will degrade to a compiler barrier on !SMP.
> 
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> 
> Index: linux-work/kernel/irq/manage.c
> ===================================================================
> --- linux-work.orig/kernel/irq/manage.c	2007-10-18 11:22:16.000000000 +1000
> +++ linux-work/kernel/irq/manage.c	2007-10-18 11:22:20.000000000 +1000
> @@ -33,6 +33,7 @@ void synchronize_irq(unsigned int irq)
>  	if (irq >= NR_IRQS)
>  		return;
>  
> +	smp_mb();
>  	while (desc->status & IRQ_INPROGRESS)
>  		cpu_relax();
>  }
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Hi,

I have read this thread and I concluded few things:

1) It is impossible to know that the card won't send more interrupts:
Even if I do a read from the device, the IRQ can be pending in the bus/APIC
It is even possible (and likely) that the IRQ line will be shared, thus the 
handler can be called by non-relevant device.

2) the synchronize_irq(); in .suspend is useless:
an IRQ can happen immediately after this synchronize_irq();
and interrupt even the .suspend()
(At least theoretically)


Thus I now understand that .suspend() should do:

	saa_writel(SAA7134_IRQ1, 0);
	saa_writel(SAA7134_IRQ2, 0);
	saa_writel(SAA7134_MAIN_CTRL, 0);

	dev->insuspend = 1;
	smp_wmb();

	/* at that point the _request to disable card's IRQs was issued, we don't know 
	   that there will be no irqs anymore.
	   the smp_mb(); guaranties that the IRQ handler will bail out in that case. */
	
	/* .......*/

	pci_save_state(pci_dev);
	pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
	return 0;

and the interrupt handler:

	smp_rmb();
	if (dev->insuspend)
		goto out;

Am I right?
	Best regards,
		Maxim Levitsky

  parent reply	other threads:[~2007-10-20  2:03 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-18  1:25 [PATCH] synchronize_irq needs a barrier Benjamin Herrenschmidt
2007-10-18  1:25 ` Benjamin Herrenschmidt
2007-10-18  1:45 ` Andrew Morton
2007-10-18  1:45   ` Andrew Morton
2007-10-18  1:55   ` Benjamin Herrenschmidt
2007-10-18  1:55     ` Benjamin Herrenschmidt
2007-10-18  2:12 ` Linus Torvalds
2007-10-18  2:12   ` Linus Torvalds
2007-10-18  2:40   ` Benjamin Herrenschmidt
2007-10-18  2:40     ` Benjamin Herrenschmidt
2007-10-18  2:57     ` Benjamin Herrenschmidt
2007-10-18  2:57       ` Benjamin Herrenschmidt
2007-10-18 14:56       ` Herbert Xu
2007-10-18 14:56         ` Herbert Xu
2007-10-18 22:05         ` Benjamin Herrenschmidt
2007-10-18 22:05           ` Benjamin Herrenschmidt
2007-10-18 22:52           ` Linus Torvalds
2007-10-18 22:52             ` Linus Torvalds
2007-10-18 23:17             ` Benjamin Herrenschmidt
2007-10-18 23:17               ` Benjamin Herrenschmidt
2007-10-18 23:39               ` Linus Torvalds
2007-10-18 23:39                 ` Linus Torvalds
2007-10-18 23:52                 ` Benjamin Herrenschmidt
2007-10-18 23:52                   ` Benjamin Herrenschmidt
2007-10-19  2:32                 ` Herbert Xu
2007-10-19  2:32                   ` Herbert Xu
2007-10-19  2:52                   ` Nick Piggin
2007-10-19  2:52                     ` Nick Piggin
2007-10-19  3:28                     ` Herbert Xu
2007-10-19  3:28                       ` Herbert Xu
2007-10-19  4:49                       ` Nick Piggin
2007-10-19  4:49                         ` Nick Piggin
2007-10-19  2:55                   ` Linus Torvalds
2007-10-19  2:55                     ` Linus Torvalds
2007-10-19  3:26                     ` Linus Torvalds
2007-10-19  3:26                       ` Linus Torvalds
2007-10-19  4:11                       ` Benjamin Herrenschmidt
2007-10-19  4:11                         ` Benjamin Herrenschmidt
2007-10-19  4:26                         ` Benjamin Herrenschmidt
2007-10-19  4:26                           ` Benjamin Herrenschmidt
2007-10-19  5:53                           ` Herbert Xu
2007-10-19  5:53                             ` Herbert Xu
2007-10-19  4:20                       ` Herbert Xu
2007-10-19  4:20                         ` Herbert Xu
2007-10-19  4:29                         ` Benjamin Herrenschmidt
2007-10-19  4:29                           ` Benjamin Herrenschmidt
2007-10-19  4:35                         ` Benjamin Herrenschmidt
2007-10-19  4:35                           ` Benjamin Herrenschmidt
2007-10-19  4:48                         ` Herbert Xu
2007-10-19  4:48                           ` Herbert Xu
2007-10-19  4:58                           ` Benjamin Herrenschmidt
2007-10-19  4:58                             ` Benjamin Herrenschmidt
2007-10-21 21:10                             ` 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-23  3:26                                 ` Herbert Xu
2007-10-19  5:36                         ` [NET]: Fix possible dev_deactivate race condition Herbert Xu
2007-10-19  5:36                           ` Herbert Xu
2007-10-19  5:38                           ` David Miller
2007-10-19  5:38                             ` David Miller
2007-10-19  7:35                           ` Peter Zijlstra
2007-10-19  7:35                             ` Peter Zijlstra
2007-10-19  9:29                             ` Herbert Xu
2007-10-19  9:29                               ` Herbert Xu
2007-10-18 14:35     ` [PATCH] synchronize_irq needs a barrier Herbert Xu
2007-10-18 14:35       ` Herbert Xu
2007-10-18 21:35       ` Benjamin Herrenschmidt
2007-10-18 21:35         ` Benjamin Herrenschmidt
2007-10-20  2:02 ` Maxim Levitsky [this message]
2007-10-20  2:02   ` Maxim Levitsky
2007-10-20  2:25   ` Linus Torvalds
2007-10-20  2:25     ` Linus Torvalds
2007-10-20  3:10     ` Maxim Levitsky
2007-10-20  3:10       ` Maxim Levitsky
2007-10-20  4:06       ` Benjamin Herrenschmidt
2007-10-20  4:06         ` Benjamin Herrenschmidt
2007-10-20  4:04     ` Benjamin Herrenschmidt
2007-10-20  4:04       ` Benjamin Herrenschmidt
2007-10-20  4:09       ` Benjamin Herrenschmidt
2007-10-20  4:09         ` Benjamin Herrenschmidt
2007-10-20  3:37   ` Herbert Xu
2007-10-20  3:37     ` Herbert Xu
2007-10-20  3:56   ` Benjamin Herrenschmidt
2007-10-20  3:56     ` Benjamin Herrenschmidt
2007-10-20  4:24     ` Maxim Levitsky
2007-10-20  4:24       ` Maxim Levitsky
2007-10-20  5:04       ` Benjamin Herrenschmidt
2007-10-20  5:04         ` Benjamin Herrenschmidt
2007-10-20  5:36         ` Maxim Levitsky
2007-10-20  5:36           ` Maxim Levitsky
2007-10-20  5:46           ` Benjamin Herrenschmidt
2007-10-20  5:46             ` Benjamin Herrenschmidt
2007-10-20  6:06             ` Maxim Levitsky
2007-10-20  6:06               ` Maxim Levitsky
2007-10-20  6:13               ` Benjamin Herrenschmidt
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=200710200402.43106.maximlevitsky@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=torvalds@linux-foundation.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.