[RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Seiji Aguchi]

Hi,

[Upstream status]
   Discussion about kmsg_dump() in kdump path: 
    - Eric and Vivek are worried about reliability of existing kmsg_dump().
    - Especially, Vivek would like to remove a RCU  function call chain in kdump path
　　　 which kernel modules can register their function calls freely. 

   Discussion about pstore in nmi_hander.
    - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.
    

[Build Status]
  Built this patch on 3.0.0-rc6-mm1 in x86_64.

[Patch Description]

 For meeting Eric/Vivek's requirements and solving an issue of pstore in nmi_hander due to mutex_lock,
 I propose following patches.

  [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path

        Some people who are not familiar with kexec may add function calls getting 
        spin_lock/mutex_lock in kexec path. These function calls causes failure of kexec. 
        So, I suggest replace a call chain with static function calls so that we can keep 
        reliability of kexec.

        APEI storage backend will work well in kexec path by applying this patch.

        Summary of this patch:
        - Call pstore_kmsg_dump_in_interrupt() directly in kexec path
        - Remove mutex_lock in pstore_dump() of kexec path

  [RFC][PATCH -mmotm 2/4] Remove mutex_lock from pstore in panic path

        Pstore must not take mutex_lock in panic path as well as kexec path 
        because panic() is called in interrupt context like nmi_handler.
        APEI storage backend will work well in panic path with this patch.

        Summary of this patch:
        - Remove kmsg_dump(KMSG_DUMP_PANIC)
        - Call pstore_kmsg_dump_in_interrupt() directly in panic path
        - Remove mutex_lock in pstore_dump() of panic path

  [RFC][PATCH -mmotm 3/4] pstore: mtdoops support

        - Pstore can support mtdoops with this patch.

  [RFC][PATCH -mmotm 4/4] pstore: ramoops support

        - Pstore can support ramoops with this patch.

Re: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Vivek Goyal]

On Tue, Jul 19, 2011 at 02:23:26PM -0400, Seiji Aguchi wrote:
> Hi,
> 
> [Upstream status]
>    Discussion about kmsg_dump() in kdump path: 
>     - Eric and Vivek are worried about reliability of existing kmsg_dump().
>     - Especially, Vivek would like to remove a RCU  function call chain in kdump path
> 　　　 which kernel modules can register their function calls freely. 
> 
>    Discussion about pstore in nmi_hander.
>     - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.

You did not answer my questions in the last posting mail thread and gone
ahead with the new posting. How are we supposed to discuss something. This
has been a problem on this mail thread since the beginneing. There is
little open discussion. 

So if you want to make any progress in this direction, what will help
is open discussion.

Locking is going to be a problem. So atleast we can remove kmsg_dump()
infrastructure from reboot path. Why can't we log something in user
space when user initiates a reboot, let it get logged in /var/log/messages
and then umount the file root and go ahead with reboot. Why does kernel
need to capture that info in NVRAM.

If we can get rid of all the logging thing on reboot path, then at least
it does not need to be lock protected with crash path.

Thanks
Vivek

RE: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Seiji Aguchi]

Hi,

>Why can't we log something in user
>space when user initiates a reboot, let it get logged in /var/log/messages
>and then umount the file root and go ahead with reboot. Why does kernel
>need to capture that info in NVRAM.

Thank you for coordinating discussion.
I will reply to your question.

Regards,

Seiji

>-----Original Message-----
>From: Vivek Goyal [mailto:vgoyal@redhat.com]
>Sent: Tuesday, July 19, 2011 2:48 PM
>To: Seiji Aguchi
>Cc: kexec@lists.infradead.org; linux-kernel@vger.kernel.org; linux-mtd@lists.infradead.org; Eric W. Biederman; KOSAKI
>Motohiro; Americo Wang; Matthew Garrett; tony.luck@intel.com; Andrew Morton; Jarod Wilson; hpa@zytor.com;
>dzickus@redhat.com; dle-develop@lists.sourceforge.net; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path
>
>On Tue, Jul 19, 2011 at 02:23:26PM -0400, Seiji Aguchi wrote:
>> Hi,
>>
>> [Upstream status]
>>    Discussion about kmsg_dump() in kdump path:
>>     - Eric and Vivek are worried about reliability of existing kmsg_dump().
>>     - Especially, Vivek would like to remove a RCU  function call chain in kdump path
>> 　　　 which kernel modules can register their function calls freely.
>>
>>    Discussion about pstore in nmi_hander.
>>     - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.
>
>You did not answer my questions in the last posting mail thread and gone
>ahead with the new posting. How are we supposed to discuss something. This
>has been a problem on this mail thread since the beginneing. There is
>little open discussion.
>
>So if you want to make any progress in this direction, what will help
>is open discussion.
>
>Locking is going to be a problem. So atleast we can remove kmsg_dump()
>infrastructure from reboot path. Why can't we log something in user
>space when user initiates a reboot, let it get logged in /var/log/messages
>and then umount the file root and go ahead with reboot. Why does kernel
>need to capture that info in NVRAM.
>
>If we can get rid of all the logging thing on reboot path, then at least
>it does not need to be lock protected with crash path.
>
>Thanks
>Vivek

RE: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path

[Seiji Aguchi]

Hi Vivek,

> Why can't we log something in user space when user initiates a reboot,
> Why does kernel need to capture that info in NVRAM.

 As I explained in following thread, 
 customers sometimes ask us to investigate the reason why system reboots.
 
 https://lkml.org/lkml/2010/11/17/249
 
 We can solve following scenario by logging messages in kernel space.

  - Syslogd is killed by mistake.
    (user kills syslogd with command or other applications send signal).
  - And then, system reboots.

 If we log messages in user space, we can't see messages.

Seiji

>-----Original Message-----
>From: Vivek Goyal [mailto:vgoyal@redhat.com]
>Sent: Tuesday, July 19, 2011 2:48 PM
>To: Seiji Aguchi
>Cc: kexec@lists.infradead.org; linux-kernel@vger.kernel.org; linux-mtd@lists.infradead.org; Eric W. Biederman; KOSAKI
>Motohiro; Americo Wang; Matthew Garrett; tony.luck@intel.com; Andrew Morton; Jarod Wilson; hpa@zytor.com;
>dzickus@redhat.com; dle-develop@lists.sourceforge.net; Satoru Moriya
>Subject: Re: [RFC][PATCH -mmotm 0/4] Improvement of pstore/kmsg_dump in kexec/panic path
>
>On Tue, Jul 19, 2011 at 02:23:26PM -0400, Seiji Aguchi wrote:
>> Hi,
>>
>> [Upstream status]
>>    Discussion about kmsg_dump() in kdump path:
>>     - Eric and Vivek are worried about reliability of existing kmsg_dump().
>>     - Especially, Vivek would like to remove a RCU  function call chain in kdump path
>> 　　　 which kernel modules can register their function calls freely.
>>
>>    Discussion about pstore in nmi_hander.
>>     - Don Zickus found an issue of pstore in nmi_handler due to its mutex_lock.
>
>You did not answer my questions in the last posting mail thread and gone
>ahead with the new posting. How are we supposed to discuss something. This
>has been a problem on this mail thread since the beginneing. There is
>little open discussion.
>
>So if you want to make any progress in this direction, what will help
>is open discussion.
>
>Locking is going to be a problem. So atleast we can remove kmsg_dump()
>infrastructure from reboot path. Why can't we log something in user
>space when user initiates a reboot, let it get logged in /var/log/messages
>and then umount the file root and go ahead with reboot. Why does kernel
>need to capture that info in NVRAM.
>
>If we can get rid of all the logging thing on reboot path, then at least
>it does not need to be lock protected with crash path.
>
>Thanks
>Vivek