From: Andi Kleen <andi@firstfloor.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
paul@mad-scientist.net, linux-kernel@vger.kernel.org
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing
Date: Wed, 27 May 2009 01:41:09 +0200 [thread overview]
Message-ID: <20090526234109.GL846@one.firstfloor.org> (raw)
In-Reply-To: <20090526162821.02e11d5b.akpm@linux-foundation.org>
On Tue, May 26, 2009 at 04:28:21PM -0700, Andrew Morton wrote:
> On Wed, 27 May 2009 01:14:28 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
> > On Tue, May 26, 2009 at 04:00:17PM -0700, Andrew Morton wrote:
> > > dump_write() doesn't seem right, either. If ->write() returns, say,
> > > 100 then the dump should keep on going. At present it treats this
> > > return as an error.
> >
> > I think that's correct actually. Short write typically means serious
> > issue like disk full or broken pipe, so stopping is good.
>
> But we shouldn't assume that. It could be that the ->write
> implementation is perfectly able to absorb the remaining data.
Maybe in theory, but in practice that's unlikely isn't it?
Disk is full or pipe is blocking etc.
> We should only error out of the write() returned zero or -EFOO.
> The current code is simply buggy, but got lucky.
Maybe very pedantically, but I would argue that most programs
don't do what you're saying (retry on any short write) and
it's actually not very nice to always write a loop for each write.
Also any IO device who relies on that would likely find
that it won't work with a lot of software.
So I think the current behaviour is ok, just need to get
rid of the signals.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2009-05-26 23:34 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
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 [this message]
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=20090526234109.GL846@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@mad-scientist.net \
/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.