RE: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?

[Robert White]

Howdy,

All threads within the same process must have the same (single) list of open
files or bad things will happen.  I understand that CLONE_FILES makes this
true at the time of the clone but I don't know if that keeps this true
thereafter (e.g I don't know if this is a copy-that or a share-that
operation).  If it doesn't, the some mechanism that does needs to be added.

If all the co-joined threads of a process share the same file descriptor
list then /proc/self/fd/* will have unity for the overall process and the
bulk of the argument disappears completely.

The reason the threads must share the file descriptor table involves the
fact that data may, and likely will, flow between the threads.  After the
open(2) call the file descriptor is just data and it will get shared.

For instance, I have a seriously multi-threaded server application.  The
listen() operation for new clients happens in one thread.  When a connection
is accept()ed I take the request (first bit of data) and match it to the
service (and therefore thread) that it should be attached too.  Then I had
that socket over to that thread.

Without the shared file descriptors this would break very badly.

Conversely, there is virtually no sane model where having a disjoint file
descriptor list but otherwise conjoined data space makes sense.  The file
descriptors are going to be "tarnishing" the data space if you do this, and
that is just begging for exploits and "surprises".  That is, you will end up
with little tidbits of data that are conditionally meaningful scattered
throughout your data space.

Where you need to have the initial data shared but differing descriptor
tables you *should* be "stuck" with a classic fork() operation.

What possible win could you have in having a variable contain a particular
integral quantity that is a data file open for reading in one thread, a
mapped segment of memory in another, and invalid in the rest?  If you don't
constrain that behavior now the resulting code that "depends" on this
behavior will plague this platform for years (see Windows Dynamic Data
Exchange) and lots of existing expectations for thread behavior will be
violated day-1 of the release.

IMHO of course 8-)

Rob.


-----Original Message-----
From: linux-kernel-owner@xxxxxxxxxxxxxxx
[mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Linus Torvalds
Sent: Thursday, October 02, 2003 5:41 PM
To: Albert Cahalan
Cc: Ulrich Drepper; Mikael Pettersson; Kernel Mailing List
Subject: Re: Who changed /proc/<pid>/ in 2.6.0-test5-bk9?


On 2 Oct 2003, Albert Cahalan wrote:
> 
> No. I mean "ban" like we ban CLONE_THREAD w/o CLONE_DETACHED.

No. Let's not do that.

We ban only things that do not make sense. That was true of trying to 
share signal handlers with different address spaces. But it is _not_ true 
of having separate file descriptors for different threads.

I don't imagine anybody cares _that_ deeply about fuser that it can't 
afford to recurse into thread directories.

And it may or may not make sense to not have a "/proc/<nn>/task/<yy>/fd"
directory at all if the thread shares file descriptors with the thread 
group leader. That would be a fairly easy optimization.

		Linus

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


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