x86_64: Asynchronous IPI broken

[Petr Vandrovec]

Hello,
  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 ak@xxxxxxx 
#   [PATCH] x86_64: Don't wait on panic
#   
#   Don't wait for a response from other CPUs on panic
#   
#   Signed-off-by: Andi Kleen <ak@xxxxxxx>
#   Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
#   Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
# 
# arch/x86_64/kernel/smp.c
#   2004/11/02 06:40:36-08:00 ak@xxxxxxx +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!

					Thanks,
						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}
       <ffffffffa03400d3>{:vmmon:LinuxDriver_Ioctl+403} 
       <ffffffffa033f079>{:vmmon:LinuxDriver_Ioctl32_Handler+89}
       <ffffffff801a497d>{compat_sys_ioctl+189} <ffffffff8012a2ab>{sys32_sigreturn+219}
       <ffffffff80122a81>{ia32_sysret+0}

Code: 00 00 00 00 00 00 00 00 d0 87 b0 7e 00 01 00 00 30 2a 13 80

Attachment: rhtest.tar.gz
Description: Binary data