All of lore.kernel.org
 help / color / mirror / Atom feed
* kdump with /proc/oldproc
@ 2011-05-17 17:30 Nathan D Miller
  2011-05-18  2:28 ` WANG Cong
  0 siblings, 1 reply; 3+ messages in thread
From: Nathan D Miller @ 2011-05-17 17:30 UTC (permalink / raw)
  To: kexec


[-- Attachment #1.1: Type: text/plain, Size: 995 bytes --]



Hello-

Has anyone tried reconstituting a portion of the old kernel's /proc while
in the capture kernel?

I had the idea while digging through the kexec/kdump code and it seemed
intriguing.

It might be a means by which user-space dump applications running under the
capture kernel could interrogate the old system, and identify bad processes
that instigated the panic.  In particular, I'm thinking of Out Of Memory
scenarios.   We've modified our kernel to panic instead of invoking the
kernel's OOM killer, but we still have the problem of identifying the "bad"
process while running in the capture kernel.

Perhaps everything could be accomplished using some sort of FUSE
file-system around /proc/oldmem and /proc/vmcore.  Not all the proc/<pid>/
files would need to be implemented, of course.  In addition, each old
process could have its own 'vmcore' file for getting a core dump of the
original process.

What do you think?  Am I tilting at windmills here?

Nate

[-- Attachment #1.2: Type: text/html, Size: 1366 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kdump with /proc/oldproc
  2011-05-17 17:30 kdump with /proc/oldproc Nathan D Miller
@ 2011-05-18  2:28 ` WANG Cong
  2011-05-18  7:00   ` Maxim Uvarov
  0 siblings, 1 reply; 3+ messages in thread
From: WANG Cong @ 2011-05-18  2:28 UTC (permalink / raw)
  To: kexec

On Tue, 17 May 2011 12:30:58 -0500, Nathan D Miller wrote:

> Hello-
> 
> Has anyone tried reconstituting a portion of the old kernel's /proc
> while in the capture kernel?
> 
> I had the idea while digging through the kexec/kdump code and it seemed
> intriguing.
> 
> It might be a means by which user-space dump applications running under
> the capture kernel could interrogate the old system, and identify bad
> processes that instigated the panic.  In particular, I'm thinking of Out
> Of Memory scenarios.   We've modified our kernel to panic instead of
> invoking the kernel's OOM killer, but we still have the problem of
> identifying the "bad" process while running in the capture kernel.
> 
> Perhaps everything could be accomplished using some sort of FUSE
> file-system around /proc/oldmem and /proc/vmcore.  Not all the
> proc/<pid>/ files would need to be implemented, of course.  In addition,
> each old process could have its own 'vmcore' file for getting a core
> dump of the original process.
> 

Well, actually you don't need to bother the old /proc
to find which process is the killer. The old dmesg contains
the PID/comm of the killer process, and we have a tool named
vmcore-dmesg to read out the dmesg from the vmcore.

With the utility 'crash', you can query any info of any process
in the old kernel, so why do you need a per-process vmcore anyway?

Thanks.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kdump with /proc/oldproc
  2011-05-18  2:28 ` WANG Cong
@ 2011-05-18  7:00   ` Maxim Uvarov
  0 siblings, 0 replies; 3+ messages in thread
From: Maxim Uvarov @ 2011-05-18  7:00 UTC (permalink / raw)
  To: WANG Cong; +Cc: kexec

2011/5/17 WANG Cong <xiyou.wangcong@gmail.com>:
> On Tue, 17 May 2011 12:30:58 -0500, Nathan D Miller wrote:
>
>> Hello-
>>
>> Has anyone tried reconstituting a portion of the old kernel's /proc
>> while in the capture kernel?
>>
>> I had the idea while digging through the kexec/kdump code and it seemed
>> intriguing.
>>
>> It might be a means by which user-space dump applications running under
>> the capture kernel could interrogate the old system, and identify bad
>> processes that instigated the panic.  In particular, I'm thinking of Out
>> Of Memory scenarios.   We've modified our kernel to panic instead of
>> invoking the kernel's OOM killer, but we still have the problem of
>> identifying the "bad" process while running in the capture kernel.
>>
>> Perhaps everything could be accomplished using some sort of FUSE
>> file-system around /proc/oldmem and /proc/vmcore.  Not all the
>> proc/<pid>/ files would need to be implemented, of course.  In addition,
>> each old process could have its own 'vmcore' file for getting a core
>> dump of the original process.
>>
>
> Well, actually you don't need to bother the old /proc
> to find which process is the killer. The old dmesg contains
> the PID/comm of the killer process, and we have a tool named
> vmcore-dmesg to read out the dmesg from the vmcore.
>
> With the utility 'crash', you can query any info of any process
> in the old kernel, so why do you need a per-process vmcore anyway?
>

If you use one of the latest kernel and gdb you can do it with gdb
without  crash or vmcore-dmesg.

> Thanks.
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>



-- 
Best regards,
Maxim Uvarov

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2011-05-18  7:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-17 17:30 kdump with /proc/oldproc Nathan D Miller
2011-05-18  2:28 ` WANG Cong
2011-05-18  7:00   ` Maxim Uvarov

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.