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]
Date:	Wed, 27 May 2009 10:52:38 +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

> Hey, don't look at me - blame Brian Kernighan or George Bush or
> someone.

Heh.

What I meant is: if it makes sense to retry the kernel should do that
on its own. It has better information about the circumstances anyways.
And it would make sense to put all such logic into a single place
instead of all programs.

If it doesn't we shouldn't try to force that to user space. That would be similar
to signal handling without SA_RESTART which I think nearly everyone agrees was one
of the worst APIs in Unix ever.

In most cases (e.g. out of memory) it likely doesn't make much sense to
retry anyways.

So short write always means error.


> > 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.

What do you mean?

> 
> 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
> particular codesite.
> 
> I bet glibc handles partial writes...

I just spent some time nagivating through the glibc stdio me^wmaze 
and I don't see any retry loops.

Also even if it did there would be lots of other users
(google codesearch has >23 million hits for "write")

> > a lot of things start failing.
> 
> The kernel should only fail if it has no other option.

Typically short write means no other option.

-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