lkml.org 
[lkml]   [2021]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 7/8] x86/irq: WARN_ONCE() if irq_move_cleanup is called on a pending interrupt
Date
On Wed, May 19 2021 at 14:21, H. Peter Anvin wrote:
> The current IRQ vector allocation code should be "clean" and never
> issue a IRQ_MOVE_CLEANUP_VECTOR IPI for an interrupt that could still
> be pending. This should make it possible to move it to the "normal"
> system IRQ vector range. This should probably be a three-step process:
>
> 1. Introduce this WARN_ONCE() on this event ever occurring.
> 2. Remove the self-IPI hack.
> 3. Move the IRQ_MOVE_CLEANUP_VECTOR to the sysvec range.

Second thoughts on this.

Despite having a halfways sane mechanism now, that warning still can be
triggered for remapped interrupts which can be moved from task context.

Interrupt is bound to CPU1 and moved to CPU2.

CPU0 CPU1 CPU2 Device

set_affinity() local_irq_disable()
Raise interrupt
-> pending in IRR on CPU1
remap to CPU2
(after this point all interrupts will go to CPU2)

Raise interrupt
on CPU2
handle_irq()
send_cleanup_ipi()

local_irq_enable()
handle_irq()
handle_cleanup_ipi()

Now if we move the cleanup vector up (higher priority) then CPU1 will
have:

local_irq_enable()
handle_cleanup_ipi()
WARN(irq set in IRR)

Unlikely but bound to happen.

Adding the WARN_ON() to the current code is harmless because it can't
trigger. Let me think some more about that.

Thanks,

tglx

\
 
 \ /
  Last update: 2021-05-20 16:03    [W:0.088 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site