From: yangyingliang@huawei.com (Yang Yingliang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu
Date: Mon, 7 Sep 2015 10:54:52 +0800 [thread overview]
Message-ID: <55ECFC7C.8060505@huawei.com> (raw)
In-Reply-To: <55EBF43E.8070501@linux.intel.com>
On 2015/9/6 16:07, Jiang Liu wrote:
> On 2015/9/6 12:23, Yang Yingliang wrote:
>> Hi All,
>>
>> There is a bug:
>>
>> When cpu is disabled, all irqs will be migratged to another cpu.
>> In some cases, a new affinity is different, it needed to be coppied
>> to irq's affinity. But if the type of irq is LPI, it's affinity will
>> not be coppied because of irq_set_affinity's return value.
>>
>>
>>
>> As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts
>> code and fix the migrating irq bug while cpu is offline.
>>
>> I'm trying let the core code do the migrating interrupts matter. kernel/irq/migration.c
>> depends on CONFIG_GENERIC_PENDING_IRQ, so I make it selected by CONFIG_SMP and
>> CONFIG_HOTPLUG_CPU and rename it to CONFIG_GENERIC_IRQ_MIGRATION for more general.
>> When CONFIG_GENERIC_IRQ_MIGRATION is enabled, an interrupt whose state_use_accessors
>> is not set with IRQD_MOVE_PCNTXT won't be migrated immediately in irq_set_affinity_locked().
>> So introduce irq_settings_set_move_pcntxt() helper to set the state in gic_irq_domain_map().
>>
>> With the above preparation, move the migrating interrupts code into kernel/irq/migration.c
>> and fix the bug by using irq_do_set_affinity().
> Hi Yingliang,
> As we are going to move migrate_irqs() to generic kernel
> code, and powerpc, metag, xtensa, sh, ia64 mn10300 also defines
> migrate_irqs() too. It would be great if we could consolidate
> all these.
> And as we are going to refine these code, there's another
> issue need attention. On x86, we need to allocate a CPU vector
> if an irq is directed to a CPU. So there's possibility that
> we run out of CPU vectors after CPU hot-removal. So we have a
> mechanism to detect whether we will run out of CPU vector
> after removing a CPU, and reject CPU hot-removal if that will
> happen.
> So the key point is, if we a need to allocate some sort
> of resource on the target CPUs for an irq, we need two steps
> when removing a CPU
> 1) check whether resources are available after removing the CPU,
> and reject CPU removal request if we ran out of resource
> 2) fix irqs after hot-removing the CPU.
> Thanks!
> Gerry
>
On arm, as I know, it doesn't need extra resource for an irq.
I am not sure other platform need this way besides x86.
I think we could consolidate all migrate_irqs() later. I am not
sure if it's good to do so big changing and modify other arch code in
a patchset that supposed to fix a bug of arm.
WARNING: multiple messages have this Message-ID (diff)
From: Yang Yingliang <yangyingliang@huawei.com>
To: Jiang Liu <jiang.liu@linux.intel.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Hanjun Guo <hanjun.guo@linaro.org>
Subject: Re: [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu
Date: Mon, 7 Sep 2015 10:54:52 +0800 [thread overview]
Message-ID: <55ECFC7C.8060505@huawei.com> (raw)
In-Reply-To: <55EBF43E.8070501@linux.intel.com>
On 2015/9/6 16:07, Jiang Liu wrote:
> On 2015/9/6 12:23, Yang Yingliang wrote:
>> Hi All,
>>
>> There is a bug:
>>
>> When cpu is disabled, all irqs will be migratged to another cpu.
>> In some cases, a new affinity is different, it needed to be coppied
>> to irq's affinity. But if the type of irq is LPI, it's affinity will
>> not be coppied because of irq_set_affinity's return value.
>>
>>
>>
>> As Marc and Will suggested, I refactor the arm/arm64 migrating interrupts
>> code and fix the migrating irq bug while cpu is offline.
>>
>> I'm trying let the core code do the migrating interrupts matter. kernel/irq/migration.c
>> depends on CONFIG_GENERIC_PENDING_IRQ, so I make it selected by CONFIG_SMP and
>> CONFIG_HOTPLUG_CPU and rename it to CONFIG_GENERIC_IRQ_MIGRATION for more general.
>> When CONFIG_GENERIC_IRQ_MIGRATION is enabled, an interrupt whose state_use_accessors
>> is not set with IRQD_MOVE_PCNTXT won't be migrated immediately in irq_set_affinity_locked().
>> So introduce irq_settings_set_move_pcntxt() helper to set the state in gic_irq_domain_map().
>>
>> With the above preparation, move the migrating interrupts code into kernel/irq/migration.c
>> and fix the bug by using irq_do_set_affinity().
> Hi Yingliang,
> As we are going to move migrate_irqs() to generic kernel
> code, and powerpc, metag, xtensa, sh, ia64 mn10300 also defines
> migrate_irqs() too. It would be great if we could consolidate
> all these.
> And as we are going to refine these code, there's another
> issue need attention. On x86, we need to allocate a CPU vector
> if an irq is directed to a CPU. So there's possibility that
> we run out of CPU vectors after CPU hot-removal. So we have a
> mechanism to detect whether we will run out of CPU vector
> after removing a CPU, and reject CPU hot-removal if that will
> happen.
> So the key point is, if we a need to allocate some sort
> of resource on the target CPUs for an irq, we need two steps
> when removing a CPU
> 1) check whether resources are available after removing the CPU,
> and reject CPU removal request if we ran out of resource
> 2) fix irqs after hot-removing the CPU.
> Thanks!
> Gerry
>
On arm, as I know, it doesn't need extra resource for an irq.
I am not sure other platform need this way besides x86.
I think we could consolidate all migrate_irqs() later. I am not
sure if it's good to do so big changing and modify other arch code in
a patchset that supposed to fix a bug of arm.
next prev parent reply other threads:[~2015-09-07 2:54 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-06 4:23 [RFC PATCH v1 0/4] arm/arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 1/4] genirq: Introduce irq_settings_set_move_pcntxt() helper Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 22:08 ` Thomas Gleixner
2015-09-06 22:08 ` Thomas Gleixner
2015-09-07 1:49 ` Yang Yingliang
2015-09-07 1:49 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 2/4] irqchip: GICv3: set non-percpu irqs status with _IRQ_MOVE_PCNTXT Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 5:56 ` Jiang Liu
2015-09-06 5:56 ` Jiang Liu
2015-09-07 2:03 ` Yang Yingliang
2015-09-07 2:03 ` Yang Yingliang
2015-09-07 12:32 ` Marc Zyngier
2015-09-07 12:32 ` Marc Zyngier
2015-09-07 13:24 ` Thomas Gleixner
2015-09-07 13:24 ` Thomas Gleixner
2015-09-07 14:56 ` Marc Zyngier
2015-09-07 14:56 ` Marc Zyngier
2015-09-07 14:58 ` Thomas Gleixner
2015-09-07 14:58 ` Thomas Gleixner
2015-09-07 16:33 ` Jiang Liu
2015-09-07 16:33 ` Jiang Liu
2015-09-06 4:23 ` [RFC PATCH v1 3/4] genirq: rename config GENERIC_PENDING_IRQ to GENERIC_IRQ_MIGRATION Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 4:23 ` [RFC PATCH v1 4/4] arm/arm64: fix a migrating irq bug when hotplug cpu Yang Yingliang
2015-09-06 4:23 ` Yang Yingliang
2015-09-06 5:55 ` Jiang Liu
2015-09-06 5:55 ` Jiang Liu
2015-09-07 2:33 ` Yang Yingliang
2015-09-07 2:33 ` Yang Yingliang
2015-09-06 8:07 ` [RFC PATCH v1 0/4] " Jiang Liu
2015-09-06 8:07 ` Jiang Liu
2015-09-07 2:54 ` Yang Yingliang [this message]
2015-09-07 2:54 ` Yang Yingliang
2015-09-07 1:54 ` Jiang Liu
2015-09-07 1:54 ` Jiang Liu
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=55ECFC7C.8060505@huawei.com \
--to=yangyingliang@huawei.com \
--cc=linux-arm-kernel@lists.infradead.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.