All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Pallipadi\, Venkatesh" <venkatesh.pallipadi@intel.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>, "Li\,
	Shaohua" <shaohua.li@intel.com>, Gary Hade <garyhade@us.ibm.com>,
	"mingo\@elte.hu" <mingo@elte.hu>,
	"mingo\@redhat.com" <mingo@redhat.com>,
	"tglx\@linutronix.de" <tglx@linutronix.de>,
	"hpa\@zytor.com" <hpa@zytor.com>,
	"x86\@kernel.org" <x86@kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lcm\@us.ibm.com" <lcm@us.ibm.com>,
	suresh.b.siddha@intel.com
Subject: Re: [PATCH] irq, x86: Remove IRQ_DISABLED check in process context IRQ move
Date: Mon, 13 Apr 2009 18:40:16 -0700	[thread overview]
Message-ID: <m18wm46min.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090413222058.GB8211@linux-os.sc.intel.com> (Venkatesh Pallipadi's message of "Mon\, 13 Apr 2009 15\:20\:58 -0700")

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:

> As discussed in the thread here
> http://marc.info/?l=linux-kernel&m=123964468521142&w=2
>
> On Fri, Apr 10, 2009 at 3:02 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> It looks like some additional bugs have slipped in since last I looked.
>>
>> set_irq_affinity does this:
>> ifdef CONFIG_GENERIC_PENDING_IRQ
>>        if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) {
>>                cpumask_copy(desc->affinity, cpumask);
>>                desc->chip->set_affinity(irq, cpumask);
>>        } else {
>>                desc->status |= IRQ_MOVE_PENDING;
>>                cpumask_copy(desc->pending_mask, cpumask);
>>        }
>> #else
>>
>> That IRQ_DISABLED case is a software state and as such it has nothing to
>> do with how safe it is to move an irq in process context.
>>
>
> "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> writes:
>> On Sat, 2009-04-11 at 04:01 -0700, Eric W. Biederman wrote:
>> >
>> > If the goal is moving MSIs, we should modify the msi code to be safe
>> > in process context and to set IRQ_MOVE_PCNTXT.
>> >
>> > The only reason we migrate MSIs in interrupt context today is that there
>> > wasn't infrastructure for support migration both in interrupt context
>> > and outside of it.
>>
>> Yes. The idea here was to force the MSI migration to happen in process
>> context. One of the patches in the series did
>>
>>         disable_irq(dev->irq);
>>         irq_set_affinity(dev->irq, cpumask_of(dev->cpu));
>>         enable_irq(dev->irq);
>>
>> with the above patch adding irq/manage code check for interrupt disabled
>> and moving the interrupt in process context.
>>
>> IIRC, there was no IRQ_MOVE_PCNTXT when we were developing this HPET
>> code and we ended up having this ugly hack. IRQ_MOVE_PCNTXT was there
>> when we eventually submitted the patch upstream. But, looks like I did a
>> blind rebasing instead of using IRQ_MOVE_PCNTXT in hpet MSI code. That
>> was my fault. Will send a patch to fix this ugliness.
>
> Below patch fixes this. i.e., revert
> commit 932775a4ab622e3c99bd59f14cc7d96722f79501
> and add PCNTXT to HPET MSI setup. Also removes copying of desc->affinity
> in generic code as set_affinity routines are doing it internally.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>

This looks good.

Do you think you could take this one step farther, place a read
after the hpet_msi_write to flush the write to the interrupt source, 
and then finish up the work to change the irq reception setup?

Roughly like ir_set_msi_irq_affinity?

That way we really do get everything done in process context.

> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> ---
>  arch/x86/kernel/apic/io_apic.c |    2 ++
>  kernel/irq/manage.c            |    5 ++---
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> index 767fe7e..aaf8212 100644
> --- a/arch/x86/kernel/apic/io_apic.c
> +++ b/arch/x86/kernel/apic/io_apic.c
> @@ -3667,12 +3667,14 @@ int arch_setup_hpet_msi(unsigned int irq)
>  {
>  	int ret;
>  	struct msi_msg msg;
> +	struct irq_desc *desc = irq_to_desc(irq);
>  
>  	ret = msi_compose_msg(NULL, irq, &msg);
>  	if (ret < 0)
>  		return ret;
>  
>  	hpet_msi_write(irq, &msg);
> +	desc->status |= IRQ_MOVE_PCNTXT;
>  	set_irq_chip_and_handler_name(irq, &hpet_msi_type, handle_edge_irq,
>  		"edge");
>  
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 7e2e7dd..2734eca 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -109,10 +109,9 @@ int irq_set_affinity(unsigned int irq, const struct cpumask *cpumask)
>  	spin_lock_irqsave(&desc->lock, flags);
>  
>  #ifdef CONFIG_GENERIC_PENDING_IRQ
> -	if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) {
> -		cpumask_copy(desc->affinity, cpumask);
> +	if (desc->status & IRQ_MOVE_PCNTXT)
>  		desc->chip->set_affinity(irq, cpumask);
> -	} else {
> +	else {
>  		desc->status |= IRQ_MOVE_PENDING;
>  		cpumask_copy(desc->pending_mask, cpumask);
>  	}
> -- 
> 1.6.0.6

  reply	other threads:[~2009-04-14  1:40 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08 21:07 [PATCH 2/3] [BUGFIX] x86/x86_64: fix CPU offlining triggered inactive device IRQ interrruption Gary Hade
2009-04-08 22:30 ` Yinghai Lu
2009-04-08 23:37   ` Gary Hade
2009-04-08 23:58     ` Yinghai Lu
2009-04-08 23:59       ` Yinghai Lu
2009-04-09 19:17         ` Gary Hade
2009-04-09 22:38           ` Yinghai Lu
2009-04-10  0:53             ` Gary Hade
2009-04-10  1:29 ` Eric W. Biederman
2009-04-10 20:09   ` Gary Hade
2009-04-10 22:02     ` Eric W. Biederman
2009-04-11  7:44       ` Yinghai Lu
2009-04-11  7:51       ` Yinghai Lu
2009-04-11 11:01         ` Eric W. Biederman
2009-04-13 17:41           ` Pallipadi, Venkatesh
2009-04-13 18:50             ` Eric W. Biederman
2009-04-13 22:20               ` [PATCH] irq, x86: Remove IRQ_DISABLED check in process context IRQ move Pallipadi, Venkatesh
2009-04-14  1:40                 ` Eric W. Biederman [this message]
2009-04-14 14:06                 ` [tip:irq/urgent] x86, irq: " tip-bot for Pallipadi, Venkatesh
2009-04-12 19:32 ` [PATCH 2/3] [BUGFIX] x86/x86_64: fix CPU offlining triggered inactive device IRQ interrruption Eric W. Biederman
2009-04-13 21:09   ` Gary Hade

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=m18wm46min.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=garyhade@us.ibm.com \
    --cc=hpa@zytor.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mingo@redhat.com \
    --cc=shaohua.li@intel.com \
    --cc=suresh.b.siddha@intel.com \
    --cc=tglx@linutronix.de \
    --cc=venkatesh.pallipadi@intel.com \
    --cc=x86@kernel.org \
    --cc=yhlu.kernel@gmail.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.