[lkml]   [2005]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux Kernel Dump Summit 2005
On Wed, 19 Oct 2005, "Theodore Ts'o" wrote:
> On Tue, Oct 18, 2005 at 03:10:24PM +0100, Hugh Dickins wrote:
> > On Tue, 18 Oct 2005, OBATA Noboru wrote:
> > >
> > > I have a bitter experience in analyzing a partial dump. The
> > > dump completely lacks the PTE pages of user processes and I had
> > > to give up analysis then. A partial dump has a risk of failure
> > > in analysis.
> >
> > Page tables of user processes are very often essential in a dump.
> > Data pages of user processes are almost always just a waste of
> > space and time in a dump. Please don't judge against partial
> > dumps on the basis of one that was badly selected.

My apologies. What should be blamed was the bad partial dump
implementation and not the partial dump itself.

But I don't think data pages of user processes are almost always
useless, as Ted comments.

> We've had hard-to-reproduce problems out in the field where being able
> to find the data pages of the user process was critical to figuring
> out what the heck was going on. So I wouldn't be quite so eager to
> dismiss the need for user pages. There are times when they come in
> quite handy....

I agree.

When a system crashed, a user may want to _avoid_ the cause of
crash and continue operation, until bugs are fixed and well

Then we try to find the way to avoid the specific situation that
has caused the crash. Sometimes it can be done by changing
resource limits, timeouts, or some fancy features in XXX.conf of
user programs.

To investigate the behavior of user processes, having data pages
of user processes in a dump is mandatory.


OBATA Noboru (

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-10-27 09:55    [W:0.074 / U:0.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site