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



  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.