NOVA: remote revoke

Norman Feske norman.feske at ...1...
Tue Jul 24 23:39:47 CEST 2012

Hello again,

> NF> what do you mean by "full revoke of the range"?
> NF>
> NF> If a PD cap goes away, won't this implicitly revoke everything from
> NF> the PD anyway? (including the not-yet-finished range of the preempted
> NF> revoke operation) If so, this looks like a non-issue to me. Or does
> NF> the preempted revoke happen to yield to leaking resources in any way?
> What I'm saying is... an operation that starts out as a directed revoke will
> turn into a revoke on the entire subtree if the PD cap goes away while the
> revoke operation is preempted. Simply because at the time the revoke is
> restarted, the limitation "only this single PD" can no longer be applied.

it seems I slightly misunderstood your proposal. In your solution, the
revoke CRD argument refers to the address space of the the caller, not
the targeted PD, right? If so, your phrasing makes sense.

But couldn't the revoke syscall take a CRD referring to the targeted PD
as argument instead? Why the need to have the to-be-revoked range mapped
in the caller's PD at all?

Just in case you are worried about the preemption of a remote revocation
in this case: This is no problem for Genode. A PD cap vanishes in core
in the event of process destruction only. The corner case of an
eventually occurring partial revocation will be taken care of by the
destruction of the whole PD.


More information about the users mailing list