lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090526234109.GL846@one.firstfloor.org>
Date:	Wed, 27 May 2009 01:41:09 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Andi Kleen <andi@...stfloor.org>, paul@...-scientist.net,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6.27.24] Kernel coredump to a pipe is failing

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@...stfloor.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@...ux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ