Alfred Perlstein <[EMAIL PROTECTED]> writes:
> It was untested. :) I'm sure you can fix it, I've got to get some
> sleep, let me know if it works for you.
Sure. Turns out the patch doesn't work, because closef() needs
p->p_fd to be valid. This is really tricky; you either need to
protect *every* access to p->p_fd with the proc lock, or figure out
some other way of handling things.
fdfree() is currently used in a handful of places:
- in kern_exec.c, an fdcopy() / fdfree() combo is used to unshare the
file table in case it is shared (vfork()); this is a waste of time
unless the table actually *is* shared, which is easy to check.
This could replaced by a single call to a new function,
fdunshare(), which checks the reference count and does an fdcopy()
if it is greater than 1.
- in kern_exit.c, fdfree() is used to close all file descriptors and
destroy the table before turning the process into a zombie (this is
the one that's giving us trouble). This could be handled by an
fdclear() function, with the actual destruction of the filedesc and
its mutex (performed by a new fddestroy() function?) left off until
the last possible moment, after the process has been removed from
the process table.
- in kern_fork.c, one case where an fdcopy() / fdfree() combo is used
to unshare the file table (see comment above about fdunshare()) and
one case where fdfree() / fdinit() is used to completely clear the
file table (RFCFDG case). The latter could be handled by a new
- in vfs_aio.c, fdfree() is called once to destroy the aio daemon's
file table, and twice to dereference the client's file table after
it has been temporarily "borrowed" by the aio daemon. This code
gives me a headache, for several reasons (one of which is a
potential race condition similar to the one we're already seeing in
kern_exit.c; another is its rather cavalier treatment of curproc)
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message