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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox