From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: akpm@linux-foundation.org
Cc: vgoyal@redhat.com, xiyou.wangcong@gmail.com,
ebiederm@xmission.com, linux-kernel@vger.kernel.org,
jwilson@redhat.com
Subject: Re: [Patch] kexec: remove KMSG_DUMP_KEXEC (was Re: Query about kdump_msg hook into crash_kexec())
Date: Mon, 30 May 2011 14:13:33 +0900 [thread overview]
Message-ID: <4DE3277D.8070109@jp.fujitsu.com> (raw)
In-Reply-To: <20110526131028.7052a893.akpm@linux-foundation.org>
(2011/05/27 5:10), Andrew Morton wrote:
> On Thu, 3 Feb 2011 13:53:01 +0900 (JST)
> KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
>
>>>> I wrote why this is no good idea by another mail. Please see it.
>>>> Anyway you have a right to don't use this feature.
>>>>
>>>
>>> But you have not explained that why do you need to hook into crash_kexec()
>>> and you have also not explained why do you need to send out kdump_msg()
>>> notification if kdump is configured.
>>>
>>> Some detailed explanation here would help.
>>
>> Hi,
>>
>> I send it you now :)
>>
>
> What happened with this? kexec-remove-kmsg_dump_kexec.patch has two acks
> and one unexplained nack :(
http://groups.google.com/group/linux.kernel/browse_thread/thread/1084f406573d76ac/ee19e34b45f83536?lnk=raot&pli=1
At last mail, Vivek proposed move kms_dump() instead remove. and I asked following question and
I've got no response. I'm still waiting his.
> I'm sorry I've missed this mail long time.
>
>> > ---------------------------------------------------------------------
>> > @@ -74,6 +75,7 @@ NORET_TYPE void panic(const char * fmt, ...)
>> > dump_stack();
>> > #endif
>> > + kmsg_dump(KMSG_DUMP_PANIC);
>> > /*
>> > * If we have crashed and we have a crash kernel loaded let it handle
>> > * everything else.
>> > * Do we want to call this before we try to display a message?
>> > */
>> > crash_kexec(NULL);
>> > ---------------------------------------------------------------------
>> And I think to compensate for that somebody introduced additional
>> kmsg_dump(KEXEC) call inside crash_kexec() and put it under CONFIG
>> option so that one can change the behavior based on config options.
>> I think this makes the logic somewhat twisted and an unnecessary call
>> inside crash_kexec(). So until and unless there is a strong reason we
>> can get rid of KEXEC event and move kmsg_dump call before crash_kexec()
>> for now and see how does it go, IMHO.
>
>
> I think I can agree your proposal. But could you please explain why do
> you think kmsg _before_ kdump and kmsg _in_ kdump are so different?
> I think it is only C level difference. CPU don't care C function and
> anyway the kernel call kmsg_dump() because invoke second kernel even
> if you proposal applied.
> It is only curious. I'm not against your proposal.
> Thanks.
next prev parent reply other threads:[~2011-05-30 5:13 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 22:59 Query about kdump_msg hook into crash_kexec() Vivek Goyal
2011-02-01 7:19 ` Américo Wang
2011-02-01 7:33 ` Eric W. Biederman
2011-02-01 7:38 ` Américo Wang
2011-02-01 8:13 ` [Patch] kexec: remove KMSG_DUMP_KEXEC (was Re: Query about kdump_msg hook into crash_kexec()) Américo Wang
2011-02-01 15:28 ` Vivek Goyal
2011-02-01 16:06 ` Jarod Wilson
2011-02-03 0:59 ` KOSAKI Motohiro
2011-02-03 2:07 ` Vivek Goyal
2011-02-03 4:53 ` KOSAKI Motohiro
2011-05-26 20:10 ` Andrew Morton
2011-05-28 1:43 ` Eric W. Biederman
2011-05-30 7:30 ` Américo Wang
2011-05-30 5:13 ` KOSAKI Motohiro [this message]
2011-05-31 21:51 ` Vivek Goyal
2011-06-09 11:00 ` KOSAKI Motohiro
2011-06-14 22:13 ` Vivek Goyal
2011-05-31 20:58 ` Seiji Aguchi
2011-05-31 21:37 ` Vivek Goyal
2011-05-31 22:24 ` Seiji Aguchi
2011-06-02 3:26 ` Eric W. Biederman
2011-06-08 0:00 ` Andrew Morton
2011-06-09 11:15 ` KOSAKI Motohiro
2011-02-03 0:55 ` Query about kdump_msg hook into crash_kexec() KOSAKI Motohiro
2011-02-03 2:05 ` Vivek Goyal
2011-02-03 4:52 ` KOSAKI Motohiro
2011-02-03 5:20 ` KOSAKI Motohiro
2011-02-04 15:00 ` Vivek Goyal
2011-03-08 1:31 ` KOSAKI Motohiro
2011-02-04 14:58 ` Vivek Goyal
2011-02-03 18:38 ` Seiji Aguchi
2011-02-03 21:13 ` Eric W. Biederman
2011-02-03 22:08 ` Seiji Aguchi
2011-02-04 2:24 ` Américo Wang
2011-02-04 2:50 ` Vivek Goyal
2011-02-04 3:28 ` Américo Wang
2011-02-04 6:40 ` KOSAKI Motohiro
2011-02-08 16:46 ` Vivek Goyal
2011-02-08 17:35 ` Eric W. Biederman
2011-02-08 19:27 ` Vivek Goyal
2011-02-08 19:58 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DE3277D.8070109@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=jwilson@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.