> This conversation got me thinking about the DLDIOC_DOORSERVER ioctl in UV
> used to set the door handle in the kernel based on a passed-in door fd.
> By the time this ioctl is processed by dld and dls calls
> door_ki_lookup(fd), how do we know that "fd" is valid? The
> door_ki_lookup() call eventually results in a getf(fd) call, and fd is
> looked-up in "curproc"... If the ioctl message was deferred and put on a
> queue, curproc won't be dlmgmtd, right?
Yes, I think that's a problem.
Off the top of my head, I see two options:
1. Do the getf() in the stream head. This goes against the
philosophy of STREAMS since the stream head is not supposed
to know anything about the ioctls that the modules or drivers
on it might accept.
2. Add agetf() (analogous to the existing areleasef()) that
allows one to lookup a file descriptor in a specific uf_info_t
other than the one tied to curproc, and then use DB_CPID(mp)
to find the process. This goes against the philosophy of
getf()/releasef() (areleasef() appears to be a wart) but
otherwise seems possible.
--
meem
