Re: GPF in tcp_recvmsg in 2.0.32

Albert D. Cahalan (acahalan@cs.uml.edu)
Fri, 5 Dec 1997 12:50:32 -0500 (EST)


Adam D. Bradley writes:

>> The only general short-term fix I've thought of would be to
>> just copy the files structure even if CLONE_FILES is specified.
>
> Blech... I'm working on a threaded web server that assumes the current
> (normal, POSIX-threads-ish) behavior to easily/inexpensively "migrate"
> sockets from the control of one thread to another.

[some "bone-headed" possibilities]

Another bone-headed possibility:

When CLONE_FILES is active, don't really close files. Just flag
them as dead, maybe converting them into /dev/null. When an open
is attempted and there are no more slots available, grab one
marked as dead.

This means that the high water mark always remains allocated.
Oh well, at least the kernel doesn't panic. This kludge may
be a tolerable "fix" for 2.0.xx, but 2.1.xx deserves better.

This whole problem reminds me of the revoke() system call.
BSD systems have a way to force processes to give up access
to a file, such as /dev/ttyS0 for example. Good solutions
to the CLONE_FILES problem would also add revoke().