On Fri, 23 Jun 2000, Manfred Spraul wrote:
> From: "Tigran Aivazian" <tigran@veritas.com>
> >
> > 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).
>
> I don't see the the deadlock, where is the problem?
the problem is not a deadlock but the fact that locking algorithms refer
to 'current' explicitly - see the problem now?
>
> * one thread can close another threads file descriptor, so noone should rely
> on "current" for the fd synchonization.
yes, it can from userspace. when you move to kernel space and to a
different context you must lock files->file_lock (which is what
put_unused_fd() or do_close() do and what the closefd.o module didn't),
otherwise you are broken :)
> * it's possible to attach to another processes fd with
> open("/proc/<pid>/fd/<x>"), AFAICS it should be possible to close another
> processes fd with the same sequence (fs/proc/base.c, proc_lookupfd())
>
> The only problem is that this close would be asynchoneous, it's possible
> that a syscall on the closed fd is still running when force_close() returns.
yes, that is another problem - in the beginning I solved this by adding a
rw semaphore to struct file which would synchronize with fget/fput but
then I realized that that idea is broken also because you may have a read
that blocks forever even on regular files (e.g. klogd reading from
/proc/kmsg) so I would have needed a new semaphore type - time-expiring rw
semaphore but that wouldn't solve the problem anyway, it would only let
the umount context timeout and fail and I am interested in 100%-succeeding
solutions only..
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 : Mon Jun 26 2000 - 21:00:04 EST