Hi Martin!
On Fri, 23 Jun 2000, Martin Mares wrote:
> Hello!
>
> > So, I still think that at the moment there is NO (neither kernel nor
> > userspace) way to close a given process' file descriptor. To do that one
> > needs to (at least, there are lots of other issues!) enhance the lock
> > subsystem to get rid of all references to 'current' context (used for
> > deadlock avoidance detection, presumably). The only thing that *can* be
> > done now is to switch a reference to a file to another file from a
> > specially written filesystem for this very purpose. This will leak a
> > little memory until the POSIX locks are fixed but is the best one can do
> > for now.
>
> Is there any reason to close FD's of other processes except for debugging?
>
imagine you want to forcibly umount a filesystem and some process(es) keep
it busy by opening files?
Then the first thing that occur to you is to forcibly close an fd. You
write some code and investigate until you discover that it *IS*
impossible. Then you come up with an idea of implementing a special
filesystem 'nullfs' where you shift the open file to, instead of closing
it. Any subsequent io on this fd gives EIO.
that was my line of reasoning anyway...
Although I came to the conclusion that it is impossible to forcibly close
fds, the situation is not so with forcible munmap (which of course keeps
the mount point busy also). These can be happily forcibly "undone" without
having to invent a new "munmapfs" which would collect all unwanted
mappings and give away SIGSEGV on attempts to access them. As for
chdir/chroot, nullfs takes care of those in exactly the same manner as of
open fds.
Regards,
Tigran
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:26 EST