From: "HAGIO KAZUHITO(萩尾 一仁)" <k-hagio-ab@nec.com>
To: Dave Young <dyoung@redhat.com>
Cc: Prasad Koya <prasad@arista.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Lianbo Jiang <lijiang@redhat.com>, Tao Liu <ltao@redhat.com>
Subject: Re: enhance makedumpfile to dump process list from vmcore
Date: Mon, 24 Jun 2024 08:08:21 +0000 [thread overview]
Message-ID: <b4fa41af-6655-487c-a239-cc9d82956dc2@nec.com> (raw)
In-Reply-To: <CALu+AoSt=hZjm-ENnaQw5XDg-J6k7KTe_cUpLsSbtQW_t7sowA@mail.gmail.com>
Hi Dave,
thank you for your comments.
On 2024/06/24 10:52, Dave Young wrote:
> Hi Kazu,
>
> On Wed, 19 Jun 2024 at 13:45, HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@nec.com> wrote:
>>
>> On 2024/06/06 3:10, Prasad Koya wrote:
>>> Hi
>>>
>>> We use makedumpfile to read the dmesg buffer from the vmcore. We are
>>> working on adding a feature to makedumpfile to extract the "process
>>> list" from /proc/vmcore. Our main use case is to save the processes
>>> that were running at the time of kernel crash to a file on the
>>> permanent storage from the kdump kernel. We intend to read a handful
>>> of useful data for each running task: pid, parent pid, real parent
>>> pid, priority, nice value, RSS, VM size, command, utime, stime, OOM
>>> score.
>>>
>>> Process list from vmcore can probably be read using crash utility, but
>>> in our embedded system using makedumpfile to do that job makes sense
>>> for us.
>>>
>>> If such an option is useful for the general users of makedumpfile,
>>> we'd like to get more inputs and contribute to this feature.
>>
>> Hi Prasad,
>>
>> thank you for sharing the idea. But sorry, currently we are not
>> interested in implementing such a big function in makedumpfile.
>>
>> The dmesg buffer is the most important information to be able to
>> determine the cause of a crash only with it, so the --dump-dmesg option
>> was implemented in makedumpfile first once upon a time. But now we have
>> handier vmcore-dmesg command in kexec-tools, so we don't intend to add
>> other functions to makedumpfile than making a dumpfile.
>>
>> I'm not sure whether these are doable, but I would suggest a few ideas
>> instead:
>> - make e.g. vmcore-process-list command like vmcore-dmesg.
>
> Not sure if this is worth either.
I also don't think that this (dumping a process list in 2nd kernel) is
worth such a (probably) big effort, because we can make a dumpfile..
I assumed that they cannot create a dumpfile, because they know that the
crash-utility can read it from a vmcore. I'm not sure why makedumpfile
doing it makes sense to them..
> I guess it can be done with some
> crash tool scripts or a crash plugin?
Yes, agree.
>
>> - use panic notifier to dump process list to the dmesg buffer before
>> kdump, and use vmcore-dmesg to get it.
>
> It is not recommended to add these before kdump if people still want a
> reliable kdump.
Agree, a panic situation is unstable, I don't intend to recommend doing
this generally. I just thought that if they cannot create a dumpfile,
maybe they can make a module that uses the notifier, as a last resort.
Thanks,
Kazu
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2024-06-24 8:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-05 18:10 enhance makedumpfile to dump process list from vmcore Prasad Koya
2024-06-19 5:44 ` HAGIO KAZUHITO(萩尾 一仁)
2024-06-24 1:52 ` Dave Young
2024-06-24 8:08 ` HAGIO KAZUHITO(萩尾 一仁) [this message]
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=b4fa41af-6655-487c-a239-cc9d82956dc2@nec.com \
--to=k-hagio-ab@nec.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=lijiang@redhat.com \
--cc=ltao@redhat.com \
--cc=prasad@arista.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