[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
port reference leaks (was: Re: new interfaces io_close, io_reidentify, f
From: |
Marcus Brinkmann |
Subject: |
port reference leaks (was: Re: new interfaces io_close, io_reidentify, file_record_lock |
Date: |
Tue, 3 Dec 2002 19:49:00 +0100 |
User-agent: |
Mutt/1.4i |
On Mon, Nov 18, 2002 at 03:26:15PM +0100, Marcus Brinkmann wrote:
> * This is absed on Neal's patch for record file locking. I changed flock_t
> to flock64_t, as we are all 64 bit now. Also I added a lifetimer port,
> which can be used by the server to request deadname notifications on. The
> idea is that the client creates one dummy port for all record locks, and if
> the task dies, the dummy port is destroyed and the server can clean up all
> the record locks that should now go away according to POSIX.
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.
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.
This is by far not a complete list, I am sure. Below some more cases I
studied, but I have not went through all interfaces.
These cases could be problematic, but are not for special reasons:
* The crash server gets a lot of prt refs, but I think it works anyway
because it also gets the task port and implicitely checks if the task port
is valid.
* The file/dir notice changes RPCs are quite safe, as they test the port by
sending an initial change notification to the port and don't accept the port
if that fails - and it will fail for all the system ports we care about.
* file_reparent is safe as the port is deallocated when the reparented port
has no users anymore.
The following cases I am not sure about:
* fsys_startup: Is the control port deallocated when realnode has no more
users?
* fsys_getroot: When is dotdot deallocated?
* fsys_forward: The test here is if the requestor accepts fsys_startup. I
am not sure if you could setup a cycliv reference leak using this.
etc etc etc.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org address@hidden
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/
- port reference leaks (was: Re: new interfaces io_close, io_reidentify, file_record_lock,
Marcus Brinkmann <=