Re: [patch 7/8] fdmap v2 - implement sys_socket2

[Al Viro]

On Fri, Jun 08, 2007 at 05:03:57PM -0700, Linus Torvalds wrote:
> 
> 
> On Fri, 8 Jun 2007, Davide Libenzi wrote:
> >
> > On Fri, 8 Jun 2007, Linus Torvalds wrote:
> > > 
> > > You need things to be *repeatable* for debugging. No ifs, buts, or maybes 
> > > about it.
> > 
> > It all depends on how you use the file descriptor.
> 
> Read what I wrote. "for debugging".
> 
> If your code is bug-free, and does what you intend it to do, everything is 
> fine. But you wouldn't be doing debugging then, would you?
> 
> For debugging, it does _not_ depend on "how you use the file descriptor". 
> The whole _point_ is that something does something wrong. Maybe you 
> _intended_ to use the file descriptor some way, and the bug was that you 
> didn't.

Exactly.  Put it another way, randomizer is a stress-tester.  Which is
a damn useful debugging tool in its own right.  *However*, the main thing
about debugging tools is that you need to be able to turn them on and off
individually; then you get a useful information narrowing the diagnosis
down.  If you can't do that, you lose.

	Folks, the real question is whether we consider the loops blindly
shooting down the file descriptors as a supportable thing.  Correction:
whether the code written in that style *and* *correct* *with* *current*
*semantics* is sufficiently numerous and hard to notice that we need that
sort of kludges.  Because what Uli's suggesting is certainly that - a kludge
sufficient for glibc internal needs.

Note that
#define NR_FILES <some constant>

for (i = 0; i < NR_FILES; i++)
	close(i);

is simply broken.  No ifs, no buts, it's broken on the current kernel.  So
that kind of stuff needs fixing anyway; do we have enough left to make it
worth preserving?

I don't know the answer; some data would be much appreciated.  If the broken
stuff like above outnumbers the valid uses, we probably need think of some
way to catch that kind of crap anyway...  Randomizer for open() et.al.
switchable on per-process basis would be a nice tool to catch some of those,
along with instrumenting the kernel to notice massive close() on files that
hadn't been opened, etc.

As long as all we have is a handwaving about widespread and unspecified
code doing this, this and that, but not that...
-
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/