Bug 309081

Description of problem:

i386 compressed diskdump header contains incorrect panic cpu.

Version-Release number of selected component (if applicable):

2.6.9-55.9.EL

How reproducible:

Requires that a crash occur on other than cpu 0.

Steps to Reproduce:
1. On i386, force a compressed diskump crash on a cpu other than cpu 0
2. Run crash utility on dumpfile
3. Note the the wrong task is selected as the panic task. 
  
Actual results:

Wrong task is selected.

Expected results:

Correct panic task is selected.


Additional info:

Looking at a RHEL4 compressed i686 diskdump (2.6.9-55.9.ELhugemem), 
from this bugzilla:

  BZ #291641: uswxornasp01 crashed while running vxdisksetup
  https://bugzilla.redhat.com/show_bug.cgi?id=291641

It has this information in its header:

  crash> help -n
  ...
           current_cpu: 0
               nr_cpus: 4
        tasks[nr_cpus]: 231ca80
                        7aa10b0
                        cfae52f0
                        7aa05b0
  ...
  crash>

indicating that the panicking task would be 231ca80,
because .current_cpu is 0.  And therefore crash comes
up with this:

  crash> set
      PID: 0
  COMMAND: "swapper"
     TASK: 231ca80  (1 of 4)  [THREAD_INFO: 238e000]
      CPU: 0
    STATE: TASK_RUNNING (PANIC)
  crash>

But it is not the panic task:

  crash> bt
  PID: 0      TASK: 231ca80   CPU: 0   COMMAND: "swapper"
   #0 [ 238efa8] smp_call_function_interrupt at 2116c69
   #1 [ 238efb0] call_function_interrupt at fffecd6a
      EAX: 00000000  EBX: 0238e000  ECX: 02104018  EDX: 0238e000  EBP: 00493007
      DS:  007b      ESI: 00000000  ES:  007b      EDI: 023c7120
      CS:  0060      EIP: 02104041  ERR: fffffffb  EFLAGS: 00000246
   #2 [ 238efe4] default_idle at 2104041
   #3 [ 238efe8] cpu_idle at 210409e
  crash>

The actual panic task, and the diskdump operation, ran on cpu 2:

  crash> set cfae52f0
      PID: 2114
  COMMAND: "vxedpart"
     TASK: cfae52f0  [THREAD_INFO: c2f3c000]
      CPU: 2
    STATE: TASK_RUNNING (ACTIVE)
  crash> bt
  PID: 2114   TASK: cfae52f0  CPU: 2   COMMAND: "vxedpart"
   #0 [c2f3ca34] disk_dump at f892f1a2
   #1 [c2f3ca38] printk at 212292e
   #2 [c2f3ca44] freeze_other_cpus at f892eef5
   #3 [c2f3ca54] start_disk_dump at f892efa0
   #4 [c2f3ca64] try_crashdump at 213386e
   #5 [c2f3ca6c] die at 2106335
   #6 [c2f3caa0] do_page_fault at 211b249
   #7 [c2f3cb80] error_code (via page_fault) at fffecede
      EAX: 00000002  EBX: d11aa000  ECX: 07bfb802  EDX: cec2c800  EBP: cec2c880
      DS:  007b      ESI: 0241e4bf  ES:  007b      EDI: 00000000
      CS:  0060      EIP: 02285f4a  ERR: ffffffff  EFLAGS: 00010086
   #8 [c2f3cbbc] netpoll_send_skb at 2285f4a
   #9 [c2f3cbd8] write_msg at f8a7c151
  #10 [c2f3cc04] __call_console_drivers at 2122714
  #11 [c2f3cc18] release_console_sem at 2122b1d
  #12 [c2f3cc28] vprintk at 2122a67
  #13 [c2f3cc38] printk at 212292e
  #14 [c2f3cc44] do_page_fault at 211b1e7
  #15 [c2f3cd0c] error_code (via page_fault) at fffecede
      EAX: 00000002  EBX: d11aa000  ECX: 39e07a02  EDX: cec2c600  EBP: cec2c640
      DS:  007b      ESI: 0241e48c  ES:  007b      EDI: 00000000
      CS:  0060      EIP: 02285f4a  ERR: ffffffff  EFLAGS: 00010086
  #16 [c2f3cd48] netpoll_send_skb at 2285f4a
  #17 [c2f3cd64] write_msg at f8a7c151
  #18 [c2f3cd90] __call_console_drivers at 2122714
  #19 [c2f3cda4] call_console_drivers at 2122829
  #20 [c2f3cdb8] release_console_sem at 2122b1d
  #21 [c2f3cdc8] vprintk at 2122a67
  #22 [c2f3cdd8] printk at 212292e
  #23 [c2f3cde4] sd_read_capacity at f882443c
  #24 [c2f3ce68] sd_revalidate_disk at f88248f3
  #25 [c2f3ce88] rescan_partitions at 218b8a4
  #26 [c2f3ceac] blkdev_reread_part at 2223ecf
  #27 [c2f3cebc] blkdev_ioctl at 222419a
  #28 [c2f3cee0] block_ioctl at 2161b34
  #29 [c2f3cee8] dmp_ioctl_by_bdev at f8b1f07f
  #30 [c2f3cf0c] vxdmp_blkrrpart at f8b1f3ca
  #31 [c2f3cf30] dmp_revalidate at f8b35dd7
  #32 [c2f3cf34] rescan_partitions at 218b8a4
  #33 [c2f3cf58] blkdev_reread_part at 2223ecf
  #34 [c2f3cf68] blkdev_ioctl at 222419a
  #35 [c2f3cf8c] block_ioctl at 2161b34
  #36 [c2f3cf94] sys_ioctl at 216a943
  #37 [c2f3cfc0] system_call at fffec219
      EAX: 00000036  EBX: 00000006  ECX: 0000125f  EDX: 00000200
      DS:  007b      ESI: 0837a000  ES:  007b      EDI: 00000006
      SS:  007b      ESP: fee52014  EBP: fee52258
      CS:  0073      EIP: 003d67a2  ERR: 00000036  EFLAGS: 00000246
  crash>

Given this is an i686 and CONFIG_4KSTACKS, the diskdump operation
switches stacks in platform_start_crashdump(): 
  
  static inline void platform_start_crashdump(void *stackptr,
                                             crashdump_func_t dumpfunc,
                                             struct pt_regs *regs)
  {
  #ifdef CONFIG_4KSTACKS
          u32 *dsp;
          union irq_ctx * curctx;
          union irq_ctx * dumpctx;
  
          if (!stackptr)
                  dumpfunc(regs, NULL);
          else {
                  curctx = (union irq_ctx *) current_thread_info();
                  dumpctx = (union irq_ctx *) stackptr;
  
                  /* build the stack frame on the IRQ stack */
                  dsp = (u32*) ((char*)dumpctx + sizeof(*dumpctx));
                  dumpctx->tinfo.task = curctx->tinfo.task;
                  dumpctx->tinfo.real_stack = curctx->tinfo.real_stack;
                  dumpctx->tinfo.virtual_stack = curctx->tinfo.virtual_stack;
                  dumpctx->tinfo.previous_esp = current_stack_pointer();
  
                  *--dsp = (u32) NULL;
                  *--dsp = (u32) regs;
  
                  asm volatile(
                          "       xchgl   %%ebx,%%esp     \n"
                          "       call    *%%eax          \n"
                          "       xchgl   %%ebx,%%esp     \n"
                          : : "a"(dumpfunc), "b"(dsp)
                          : "memory", "cc", "edx", "ecx"
                  );
          }
  #else
          dumpfunc(regs, NULL);
  #endif
  }

When setting up the "fake" thread_info in the dumpctx stack,
it only initializes the .task, .real_stack, .virtual_stack and
.previous_esp fields.  But the .cpu field is left alone with
a value of zero (given that the passed-in stack was cleared when
allocated).

So later on when the diskdump header is set up in the disk_dump()
function, it does this:

         dump_header.current_cpu      = smp_processor_id();

which will pick up the zeroed-out cpu value in the thread_info
of the switched stack.

  #define smp_processor_id() (current_thread_info()->cpu)

Seems like we would have seen this before?  Anyway, it only
affects i686, since the only other architecture that switches
switches stacks is the x86_64, but it gets its cpu from the
per-cpu PDA structure.