[Dle-develop] [RFC][PATCH v2 -next 0/2] make pstore/kmsg_dump run after stopping other cpus in panic path

[Seiji A. <sei...@hd...>]

Hi,

 As Don mentioned in following thread, it would be nice for pstore/kmsg_dump to serialize 
 panic path and have one cpu running  because they can log messages reliably. 
 
 https://lkml.org/lkml/2011/10/13/427
 
 For realizing this idea, we have to move kmsg_dump below smp_send_stop() and bust some locks of 
 kmsg_dump/pstore in panic path. Also, we have to care about NMI interrupt.

Changelog:
 v2
  - Adding trylocks to kmsg_dump()/pstore_dump() so that they can work in NMI context.  
  - Dividing a patch into two. 
     First one is just moving kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop().
     Second one is changing lock operations in kmsg_dump()/pstore_dump().
 v1
  - moving kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop.
  - busting logbuf_lock of kmsg_dump() in panic path for avoiding deadlock.
  - busting psinfo->buf_lock of pstore_dump() in panic path for avoiding deadlock.

Patch Descriptions:
[RFC][PATCH -next v2 1/2] Moving kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop()
  - moving kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop for serializing logging 
    process via smp_send_stop.

[RFC][PATCH v2 -next 2/2] Adding lock operations to kmsg_dump()/pstore_dump()
  Adding a lock operation below in pstore_dump()
  - busting psinfo->buf_lock of pstore_dump() in panic path for avoiding deadlock.

  Adding lock operations below in kmsg_dump()
  - busting logbuf_lock of kmsg_dump() in panic path for avoiding deadlock.
  - Adding trylock for taking logbuf_lock of kmsg_dump() in NMI context. 

Seiji