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 14:01:09 -0400 [thread overview]
Message-ID: <1243360869.29250.340.camel@psmith-ubeta.netezza.com> (raw)
In-Reply-To: <1243355634.29250.331.camel@psmith-ubeta.netezza.com>
On Tue, 2009-05-26 at 12:33 -0400, Paul Smith wrote:
> 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.
I have verified that fs/pipe.c:pipe_write() is returning ERESTARTSYS as
a result of this code:
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
break;
}
I'm not exactly sure where to go from here, without knowing what the
design SHOULD be for signals that are received during core dumps.
next prev parent reply other threads:[~2009-05-26 18:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-26 16:33 [2.6.27.24] Kernel coredump to a pipe is failing Paul Smith
2009-05-26 18:01 ` Paul Smith [this message]
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=1243360869.29250.340.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.