Re: x86: Inconsistent xAPIC synchronization in arch_irq_work_raise?

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2014-01-22 19:43, Andi Kleen wrote:
>>> Huang Ying, can you explain to Jan why you do the wait afterwards?
>>
>> I borrow the code from the original MCE report event code.
>>
>> Andi, could you help us to explain it?
> 
> I don't recall all the details, but I believe i also just copied 
> it from the APIC code. I don't think I did any particular ordering
> intentionally.

OK, then let me summarize my current understanding so that we can derive
a consistent usage:

The xAPIC requires us to only write to ICR (both low and high part) if
ICR.DS is cleared - correct? ICR.DS checking as well as ICR writing must
only work against the same CPU, naturally.

Both __default_send_IPI_shortcut and __default_send_IPI_dest_field check
ICR.DS first, then write, but do not wait for ICR.DS to become 0 again -
not needed if this pattern is used consistently. Moreover,
default_send_IPI_mask* disables interrupts around these steps, thus
ensure atomicity. But shorthand IPI transmitters
(default_send_IPI_allbutself, default_send_IPI_all,
default_send_IPI_self) do not disable interrupts themselves. I didn't
check their call sites yet, maybe it's there.

Next we have x86's arch_irq_work_raise which does wait-write-wait,
either by chance or in order to work around a missing atomicity of
wait+write somewhere else. Preemption is off, interrupts remain on.

And then there is apic_icr_write, used while onlining CPUs, not only
during boot, that runs without any protection - that's the race I
originally stumbled over (INIT/SIPI or "just" NMI signals can end up on
the wrong CPU).

So now I'm looking for consistent locking rules (which type of lock, who
is responsible when issuing IPIs?) and a good (ie. also efficient) way
to apply them.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux