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!
next 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.