Re: [18.104.22.168] Kernel coredump to a pipe is failing
From: Andrew Morton
Date: Wed May 27 2009 - 03:46:34 EST
On Wed, 27 May 2009 09:31:36 +0200 Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxxxx> 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.
Hey, don't look at me - blame Brian Kernighan or George Bush or
> And the same applies to in-kernel users really.
We could delete a rather nice amount of tricky VFS code if we were to
make this assumption. But of course we daren't do that.
And as long as we're attempting to correctly handle partial writes all
over the kernel, it's a bit dopey to deliberately avoid doing this at one
I bet glibc handles partial writes...
> 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.
The kernel should only fail if it has no other option.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/