Messages in this thread | | | Date | Fri, 29 May 2009 12:34:32 +0200 | From | Pavel Machek <> | Subject | Re: [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
| |