lkml.org 
[lkml]   [2014]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: x86: Inconsistent xAPIC synchronization in arch_irq_work_raise?
    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


    \
     
     \ /
      Last update: 2014-01-23 20:46    [W:4.382 / U:0.524 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site