-
由 Yipeng Zou 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6WPFT CVE: NA -------------------------------- Recently, We have a LPI migration issue on the ARM SMP platform. For example, NIC device generates MSI and sends LPI to CPU0 via ITS, meanwhile irqbalance running on CPU1 set irq affinity of NIC to CPU1, the next interrupt will be sent to CPU2, due to the state of irq is still in progress, kernel does not end up performing irq handler on CPU2, which results in some userland service timeouts, the sequence of events is shown as follows: NIC CPU0 CPU1 Generate IRQ#1 READ_IAR Lock irq_desc Set IRQD_IN_PROGRESS Unlock irq_desc Lock irq_desc Change LPI Affinity Unlock irq_desc Call irq_handler Generate IRQ#2 READ_IAR Lock irq_desc Check IRQD_IN_PROGRESS Unlock irq_desc Return from interrupt#2 Lock irq_desc Clear IRQD_IN_PROGRESS Unlock irq_desc return from interrupt#1 For this scenario, The IRQ#2 will be lost. This does cause some exceptions. For further information, see [1]. This patch introduced a new flow handler which combines fasteoi and edge type as a workaround. An additional loop will be executed if the IRQS_PENDING has been setup. Fixes: cc2d3216 ("irqchip: GICv3: ITS command queue") Signed-off-by: NYipeng Zou <zouyipeng@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
a95cc4da