Messages in this thread | | | Date | Tue, 4 May 1999 12:28:10 -0400 (edt) | From | Sam Roberts <> | Subject | FD_CLFORK or equivalent? |
| |
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/
| |