lkml.org 
[lkml]   [2009]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.6.27.24] Kernel coredump to a pipe is failing
On Wed 2009-05-27 01:41:09, Andi Kleen wrote:
> 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.

Short writes are normal at least for pipes and sockets... better fix
the sw.

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


\
 
 \ /
  Last update: 2009-05-29 14:51    [W:0.055 / U:1.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site