From: Paul Smith <paul@mad-scientist.us>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Andi Kleen <andi@firstfloor.org>, gdb@sourceware.org
Subject: Re: Partial cores using Linux "pipe" core_pattern
Date: Tue, 26 May 2009 19:26:00 -0000 [thread overview]
Message-ID: <1243365968.29250.357.camel@psmith-ubeta.netezza.com> (raw)
In-Reply-To: <1242923544.29250.134.camel@psmith-ubeta.netezza.com>
On Thu, 2009-05-21 at 12:32 -0400, Paul Smith wrote:
> It _feels_ to me like there's some kind of COW or similar mismanagement
> of the VM for these forked processes such that they interfere and we
> can't get a full and complete core dump when all of them are dumping at
> the same time.
Well, my feelings were way off. I did more investigation and it turns
out that what's happening is that the TIF_SIGPENDING flag is being set
during the core dump. This causes the write to the pipe to stop, and
the core dumping code makes no effort to manage errors or partial
writes. Here's the function in binfmt_elf.c that does the 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 we get back anything other than exactly the number of bytes we tried
to write, we give up and return false (0).
This definitely returns false when I see the short cores, and never when
I see "normal" cores. I modified it to see what it's getting back and
file->f_op->write() is returning ERESTARTSYS. So I annotated
fs/pipe.c:pipe_write() and I'm definitely getting it from this code, at
line 550 or so:
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
break;
}
I've been posting on the linux-kernel mailing list, so this is really
just an FYI to anyone interested in following the progress; you can find
the current end of the thread here:
http://marc.info/?l=linux-kernel&m=124336093401443&w=2
So far I've failed to gain any interest from anyone on that list but
hopefully someone will respond, who can help me figure out what to do
next.
Cheers!
prev parent reply other threads:[~2009-05-26 19:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 1:23 Paul Smith
2009-05-18 6:05 ` Paul Pluzhnikov
2009-05-18 13:22 ` Paul Smith
2009-05-18 7:25 ` Andi Kleen
2009-05-18 13:29 ` Paul Smith
2009-05-18 13:49 ` Andreas Schwab
2009-05-18 14:32 ` Paul Smith
2009-05-21 16:32 ` Paul Smith
2009-05-26 19:26 ` Paul Smith [this message]
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=1243365968.29250.357.camel@psmith-ubeta.netezza.com \
--to=paul@mad-scientist.us \
--cc=andi@firstfloor.org \
--cc=gdb@sourceware.org \
--cc=schwab@linux-m68k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox