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.
Cheers Norman