bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RPC to self with rendez-vous leading to duplicate port destroy


From: olafBuddenhagen
Subject: Re: RPC to self with rendez-vous leading to duplicate port destroy
Date: Mon, 14 Mar 2011 03:21:43 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Hi,

On Mon, Mar 14, 2011 at 01:44:20AM +0100, Samuel Thibault wrote:

> - diskfs_S_dir_lookup is called, which for some reason ends up calling
> - fshelp_fetch_root(), which calls
> - reauth(), which calls
> - mach_reply_port() to get a rendez-vous port, and then issues
> - io_reauthenticate() with that port on ext2fs itself (since it's the
>   root of the system), thus triggering a call to:
>   - diskfs_S_io_reauthenticate() in another thread.

I was wondering why the root FS would reauthenticate against itself...
But a little IRC discussion cleared this up: when a passive translator
is activated, the parent FS passes a copy of its own root directory port
(CRDIR), reauthenticated to match the user owning the node (and thus the
active translator being started). For the root FS the root directory
port points to itself.

I guess this could be special-cased; but that's not necessary as long as
reauthenticating against itself is supposed to work... Which leads to
the real question:

>   There, the
>   rendez-vous port is thus the same as the reply port obtained above,
>   with the *same name*.
> - reauth() destroys the rendez-vous port (and thus the name!)
>   - a bit later, diskfs_S_io_reauthenticate has finished its work,
>     and deallocates its rendez-vous port. But the name doesn't exist any
>     more. Bad.

I wonder, why is the rendez-vous port actually destroyed, instead of
just unreferencing the right?

-antrik-



reply via email to

[Prev in Thread] Current Thread [Next in Thread]