[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706081211050.5795@alien.or.mcafeemobile.com>
Date: Fri, 8 Jun 2007 12:21:36 -0700 (PDT)
From: Davide Libenzi <davidel@...ilserver.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Ulrich Drepper <drepper@...hat.com>,
Al Viro <viro@....linux.org.uk>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Theodore Tso <tytso@....edu>,
Eric Dumazet <dada1@...mosbay.com>,
Kyle Moffett <mrmacman_g4@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [patch 7/8] fdmap v2 - implement sys_socket2
On Fri, 8 Jun 2007, Linus Torvalds wrote:
> On Fri, 8 Jun 2007, Ulrich Drepper wrote:
> >
> > We are talking about file descriptors here. If you're using file
> > descriptors as anything other than tokens you'll find out soon enough
> > that your code is broken. The new type of file descriptors cannot be
> > used as indeces and the randomization makes sure that no program by some
> > fluke happens to work.
>
> No, Uli.
>
> 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. If you see a file
descriptor as an opaque handle (like it should be, really), that is simply
passed to the OS to use services exposed by the handle, you will be fine
independently from the values handed out by the OS. It was for the exactly
this guarantee that created the problems, with ppl relying on it for
indexing table, closing all files < NR_FILE and so on.
- Davide
-
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