[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectx86_64: Asynchronous IPI broken
    can you revert change below and/or make it safe?

    # This is a BitKeeper generated diff -Nru style patch.
    # ChangeSet
    # 2004/11/02 15:04:23-08:00
    # [PATCH] x86_64: Don't wait on panic
    # Don't wait for a response from other CPUs on panic
    # Signed-off-by: Andi Kleen <>
    # Signed-off-by: Andrew Morton <>
    # Signed-off-by: Linus Torvalds <>
    # arch/x86_64/kernel/smp.c
    # 2004/11/02 06:40:36-08:00 +6 -5
    # x86_64: Don't wait on panic

    After this change asynchronous IPIs are unusable, as 'data' is local
    variable for __smp_call_function, but __smp_call_function does not
    wait anymore for other processor(s) to fetch this data.

    Due to this smp_call_function_interrupt in better case just modifies
    random memory in atomic_inc(&call_data->started), in worse case (as
    happened to me) 'data' on stack is overwritten with other data and
    bogus function is called, triggering some fault in IPI interrupt and
    killing whole system.

    If you cannot guarantee that other processor will accept IPI,
    I'm afraid that you'll have to create much more complicated change
    than simple change you did in the change above.

    Due to this change you cannot run VMware on these kernels, as sooner
    or later kernel will die as vmmon is big source of async IPIs.

    It would be nice if you could insmod attached 'rhtest' module to check
    your eventual fix (it was originally written to prove that RHAS2.1
    kernels are broken when it comes to async IPI, but it works nice for
    this case too). It should print:

    Test done. ASYNC was ASYNC, SYNC was SYNC, nesting did not happen.
    Test passed.

    and not:

    Test done. ASYNC was ASYNC, SYNC was SYNC, nesting occured.
    Test failed.
    ASYNC IPI was completely lost!

    Petr Vandrovec

    [pasted from serial console]
    CPU 1
    Modules linked in: vmnet vmmon ide_disk sg floppy sr_mod ipx p8022 psnap llc esp6 ah6 ipcomp esp4 ah4 xfrm_user wp512 tea sha512 michael_mic md4 khazad cast6 c...
    Pid: 27622, comm: vmware-vmx Tainted: P 2.6.10-rc1-c2606
    RIP: 0010:[<000001007c509eb8>] [<000001007c509eb8>] <<<< bogus call_data->func overwritten with some data pointer
    RSP: 0000:000001007ff93fa0 EFLAGS: 00011006
    RAX: 000001001bf5ffd8 RBX: 000000008026a796 RCX: 0000000000000000
    RDX: 000001007c509eb8 RSI: 00000000000000fa RDI: 0000000000000000
    RBP: 000001001bf5f938 R08: 0000000000000010 R09: 000000005991b9f8
    R10: 000001001bf5e000 R11: 0000000000000000 R12: 0000010033595368
    R13: 0000002a95dc6090 R14: ffffffff8056bd00 R15: 00000000000006e0
    FS: 0000002a95dc6090(0000) GS:ffffffff8056bd00(005b) knlGS:000000005991bbb0
    CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
    CR2: 000001007c509eb8 CR3: 000000003ff96000 CR4: 00000000000006e0
    Process vmware-vmx (pid: 27622, threadinfo 000001001bf5e000, task 000001006fd71030)
    Stack: ffffffff8011a790 ffffff0001565000 ffffffff8010f5cd 000001001bf5f938 <EOI>
    00000000000006e0 ffffffff8056bd00 0000002a95dc6090 0000010033595368
    ffffff00015655b8 ffffff0001565000
    Call Trace:<IRQ> <ffffffff8011a790>{smp_call_function_interrupt+64}
    <ffffffff8010f5cd>{call_function_interrupt+133} <EOI> <ffffffffa0345dd7>{:vmmon:Task_Switch+2695}
    <ffffffffa034566b>{:vmmon:Task_Switch+795} <ffffffffa0347ed2>{:vmmon:Vmx86_RunVM+82}
    <ffffffff801a497d>{compat_sys_ioctl+189} <ffffffff8012a2ab>{sys32_sigreturn+219}

    Code: 00 00 00 00 00 00 00 00 d0 87 b0 7e 00 01 00 00 30 2a 13 80
    [unhandled content-type:application/octet-stream]
     \ /
      Last update: 2005-03-22 14:08    [W:0.023 / U:8.252 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site