All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Smith <paul@mad-scientist.net>
To: linux-kernel@vger.kernel.org
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing
Date: Tue, 26 May 2009 12:33:54 -0400	[thread overview]
Message-ID: <1243355634.29250.331.camel@psmith-ubeta.netezza.com> (raw)

Sorry for not following up to my previous message to get the threading
headers correct: the original is on another system I don't have access
to and I can't find a way to reply from any of the web archived
versions.  Anyway, this is a link to the original FYI:

http://marc.info/?l=linux-kernel&m=124299629611706

In that post I observed that my short cores were being caused by
dump_write() returning 0; taking another look at dump_write():

        static int dump_write(struct file *file, const void *addr, int nr)
        {
        	return file->f_op->write(file, addr, nr, &file->f_pos) == nr;
        }

If the write operation returns an error of any kind, or it fails to
write the complete set of bytes (nr here is always PAGE_SIZE, as this
function is called when it fails), then dump_write() returns 0 and we
get a short core.

So I annotated dump_write() to printk() if this operation is false, and
I get:

        file ffff8803b95d0180: dump_write: -512 < 4096

Well, -512 is ERESTARTSYS.  That, to me, seems like a reasonable error
code to get when we're trying to dump core to a pipe.  Yes?  No?

Shouldn't we be doing some kind of error handling here, at least for
basic things like signals?  Should a process that's dumping core be set
to ignore signals?  Should dump_write() try again on ERESTARTSYS?

Any advice or comments would be greatly appreciated!



             reply	other threads:[~2009-05-26 16:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-26 16:33 Paul Smith [this message]
2009-05-26 18:01 ` [2.6.27.24] Kernel coredump to a pipe is failing Paul Smith
2009-05-26 20:31 ` Andi Kleen
2009-05-26 21:09   ` Paul Smith
2009-05-26 23:00   ` Andrew Morton
2009-05-26 23:14     ` Andi Kleen
2009-05-26 23:28       ` Andrew Morton
2009-05-26 23:41         ` Andi Kleen
2009-05-26 23:45           ` Andrew Morton
2009-05-27  0:11             ` Andi Kleen
2009-05-27  0:29               ` Andrew Morton
2009-05-27  6:02                 ` Paul Smith
2009-05-27  6:17                 ` Paul Smith
2009-05-27  7:31                 ` Andi Kleen
2009-05-27  7:45                   ` Andrew Morton
2009-05-27  8:52                     ` Andi Kleen
2009-05-27  8:56                       ` Andrew Morton
2009-05-27 20:25           ` Jesper Juhl
2009-05-29 10:34           ` Pavel Machek
2009-05-27 18:31   ` Oleg Nesterov
2009-05-27 18:50     ` Andi Kleen
2009-05-27 19:05       ` Oleg Nesterov
2009-05-27 19:49         ` Paul Smith
2009-05-27 20:34           ` Oleg Nesterov
2009-05-27 20:04     ` Oleg Nesterov
2009-05-27 20:22       ` Paul Smith
  -- strict thread matches above, loose matches on Subject: below --
2009-05-22 12:34 Paul Smith

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=1243355634.29250.331.camel@psmith-ubeta.netezza.com \
    --to=paul@mad-scientist.net \
    --cc=linux-kernel@vger.kernel.org \
    /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.