|
From: Seiji A. <sei...@hd...> - 2011-10-21 21:19:47
|
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 |