Re: port reference leaks (was: Re: new interfaces io_close, io_reidentify, file_record_lock

Marcus Brinkmann <[email protected]> writes:

> This doesn't work.  Well, it would work, but it is dangerous.
> 
> Imagine that a task provides a a send right for a port that is not in the
> task, but in some other task.  For example another system filesystem, or an
> auth port.  Then the task can die, effectively leaking both resources, the
> resources of the port it provided, and the file lock.

Yeah.  

> In general, we never must accept user provided port references in the server
> "for a long time".  We already violate that!
> 
> * The auth server keeps a ref for the rendezvous port.  If that port is
>   not by the user, the user can exit and the reference is effectively leaked.
> 
> * You create a pipe, then you call io_select_request on that pipe, with the
>   reply port being the write end of the pipe itself.  Then you exit.

So we need a way other than port death notifications to handle this?
I don't think so.  I'm not certain there is a problem here.