FD_CLFORK or equivalent?

Sam Roberts (sam@cogent.ca)
Tue, 4 May 1999 12:28:10 -0400 (edt)


Hi,

This is a question about implementing a module access policy
where only the process that opened a device can have a copy
of that fd, i.e. I want the fd closed on fork().

I've implemented synchronous message passing using a loadable kernel
module, and other related functions, see:
http://toronto.qenesis.com/Sam/srr.html
for GPLed code and rationale.

I'm using fds opened on my driver to track and communicate with
participating processes, and am *relying* on a close() on that
fd to indicate that that process has died.

The problem is that when a process forks and exits, the child
will still have the fd open, so my module won't know that the
original process that opened the fd is dead, and it needs to
know so that it can unblock any processes that have blocked
on a Send() or Receive() to it.

I have a workaround coded where if the child attempts to make
a system call on that fd I detect that it is not the original
opener, and force it to close the fd and reopen its own.
However, if it never makes any calls on the fd it can hold it
open forever..., and even if it does close it there is a race
condition which is intellectually unsatisfying, and will
eventually FUBAR somebody (probably me).

Is there an existing Linux/Unix mechanism to force fds closed
on fork() that I am unaware of?

If not, before I hack one in as a private kernel patch, is
there any reason to add such a mechanism, perhaps a FD_CLOFORK
flag, and does anybody have suggestions on where to start?

TIA,
Sam

--
Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)
"News is very popular among its readers." - RFC 977 (NNTP)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/