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 09:31:36 +0200 [thread overview]
Message-ID: <20090527073136.GT846@one.firstfloor.org> (raw)
In-Reply-To: <20090526172935.fad52c49.akpm@linux-foundation.org>
On Tue, May 26, 2009 at 05:29:35PM -0700, Andrew Morton wrote:
> On Wed, 27 May 2009 02:11:04 +0200 Andi Kleen <andi@firstfloor.org> wrote:
>
> > > I dunno. Is this true of all linux filesystems in all cases? Maybe.
> >
> > Assuming one of them is not would you rather want to fix that file system
> > or 10 zillion user programs (including the kernel core dumper) that
> > get it wrong? @)
> >
>
> I think that removing one bug is better than adding one.
>
> Many filesystems will return a short write if they hit a memory
> allocation failure, for example. pipe_write() sure will. Retrying
> is appropriate in such a case.
Sorry but are you really suggesting every program in the world that uses
write() anywhere should put it into a loop? That seems just like really
bad API design to me, requiring such contortions in a fundamental
system call just to work around kernel deficiencies.
I can just imagine the programmers putting nasty comments
about the Linux kernel on top of those loops and they would
be fully deserved.
And the same applies to in-kernel users really.
The memory allocation case more sounds like a bug in these fs and
in pipe.
e.g. the network stack sleeps waiting for memory, perhaps these
file systems should too.
Or it should just always return -ENOMEM. Typically when the
system is badly out of memory you're gonna lose anyways because
a lot of things start failing.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2009-05-27 7:26 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
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 [this message]
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=20090527073136.GT846@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.