I have found the error and corrected the source code [1].
[1] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/4c02e...
The error was, that I used the same Entrypoint for managing my custom Rpc_object<Ram_session> and for passing it to the child constructor.
I think, the child constructor created an Rpc_object<Parent>, which is managed by the child's Entrypoint. Then the Rpc_object<Parent> called an RPC method from my Rpc_object<Ram_session>, which also is managed by this Entrypoint. Thus, the Entrypoint blocked on the remote procedure call to Rpc_objcet<Ram_session> waiting for itself to finish the call from Rpc_object<Ram_session>. The Rpc_object<Ram_session> needs to use this Entrypoint, but it was blocked. Thus, it went waiting for the Entrypoint.
Now Rpc_object<Parent> is waiting for Rpc_object<Ram_session> and vice vera => deadlock.
Please correct me, if I am wrong :)
Best regards Denis
On 18.08.2016 10:28, Denis Huber wrote:
Hello Norman,
thank you for your well-written answer :)
On 17.08.2016 14:06, Norman Feske wrote:
Hi Denis,
first, thank you for providing a test case in such a nicely condensed form. It is great for pin-pointing the problem.
On 14.08.2016 18:03, Denis Huber wrote:
I tried to adopt this concept for a custom Ram session. I created a very short test program [1] (Run script in [2]) which creates a custom Ram_session_component and tries to transfer quota from its environment to the custom Ram session component. The quota transfer fails with error code -1, which means the recipient of the transfer is not a valid session component [3].
I think the problem is, that I have not created a valid capability of the custom Ram_session_component. What important fact do I miss in my implementation? I am grateful for every hint you give me :)
Core's RAM service does not know the meaning behind the 'ram_special' capability because this capability does refer to an RPC object living inside your component, not inside core. Core can transfer quota only between RAM sessions known to core. It tries to look up a RAM session for the supplied capability argument but cannot find one. In contrast, if you change the transfer-quota line to
log("t: ", env.ram().transfer_quota(ram_impl._parent_ram, 4096));
the operation succeeds because 'ram_impl._parent_ram' refers to a RAM session provided by core.
This means, the Rpc_objects can communicate, if they are managed by the same Entrypoint, but not if they are in different Entrypoints. Just out of curiosity: Can I delegate a capability from one Entrypoint to another?
If you want the child subsystem to deal with multiple RAM sessions (such as 'env.ram()' and a manually created RAM connection), the "non-root" approach can no longer be applied. In order to allow the RAM sessions refer to each other, they need to be provided by the same RAM service. I.e., when creating the child, you will have to equip it with a RAM session of your RAM service as done, for example, by noux. The '_resources.ram' of the child [1] is a locally-provided RAM-session object.
Btw, you will encounter a very similar problem with the PD-session argument for the 'Cpu_session::create_thread' operation. When forwarding this RPC call to core, you will need to replace the capability argument supplied by the client (which refers to your virtualized PD session) by the "real" PD capability as known by core.
Could this explanation answer your question?
Thanks, this explanation helped me to solve the initial problem and I could also implement the PD and CPU Rpc_objects (without root objects), which intercept the child's session methods.
Now my problem is the following: If I apply your solution and start a child with a custom RAM Rpc_object, then the program hangs up on the child creation. I have created a simple program [1] (child component [2], run script [3]) to demonstrate the error. The output is
[init -> random] All is fine until now! Error: Test execution timed out Makefile:261: recipe for target 'run/random' failed make: *** [run/random] Error 254
This demonstrates that all resource-object creations before the child object creation passed without errors. But the program hangs up on the creation of the child. What could be the error?
Best regards Denis
[1] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b...
[2] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b...
[3] https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b...
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main