Hello,
In an experiment I tried making some modifications to sculpt on staging, most notably moving the file system stack onto the bottom-level init. However, opening block sessions with the drivers subsystem fails.
Simply said, if I add another part_blk component to sculpt.run as a child of init, and try to connect its Block-session to the drivers subsystem, I get the following error:
|Error: init -> drivers: attempt to transfer initial quota|| ||Warning: PD (init -> drivers) RAM limit (used=776K, limit=1089025) exceeded during transfer_quota(4207020)|| ||[init] child "drivers" requests resources: ram_quota=4207020|| ||Error: init -> drivers: attempt to transfer initial quota|| ||Warning: PD (init -> drivers) RAM limit (used=776K, limit=1089025) exceeded during transfer_quota(4207020)|| ||[init] child "drivers" requests resources: ram_quota=4207020|| ||Error: init -> drivers: attempt to transfer initial quota|| ||Warning: PD (init -> drivers) RAM limit (used=776K, limit=1089025) exceeded during transfer_quota(4207830)|| ||[init] Warning: part_blk: could not revert session RAM quota (service=Block cid=6 args='tx_buf_size=4194304, cap_quota=5, label="part_blk -> ", ram_quota=4207830, diag=0' state=SERVICE_DENIED ram_quota=4207830, cap_quota=5)|| ||[init -> part_blk] Error: Block-session creation failed (ram_quota=4208640, cap_quota=5, tx_buf_size=4194304, label="")|| ||[init -> part_blk] Error: Uncaught exception of type 'Genode::Service_denied'|| ||[init -> part_blk] Warning: abort called - thread: ep|| ||[init] child "part_blk" exited with exit value 1|
When I run part_blk in the normal fs runtime with fs.config and default_fs_subinit.config (with part_blk not commented out), it works fine. Of course I do not run both at the same time, as the ahci_drv only supports one client at a time.
The config snippet I added to sculpt.run just below the drivers init looks as follows (I copied it from default_fs_subinit.config except that my computer has an MBR partition scheme):
| <start name="part_blk" caps="100">|| || <resource name="RAM" quantum="10M"/>|| || <provides><service name="Block"/></provides>|| || <config use_gpt="no">|| || <policy label_prefix="vfs" writeable="yes" partition="1"/>|||| || </config>|| || <route>|| || <service name="Block"> <child name="drivers" label="default"/> </service>|| || <any-service> <parent/> </any-service>|| || </route>|| || </start>|
I tried giving part_blk more RAM, giving "drivers" more RAM, giving "drivers -> dynamic" more RAM and giving "drivers -> dynamic -> ahci_drv" more as well (by editing the driver_manager), but the error message persists with the same numbers as above.
Now I'm stuck on why this error occurs. One possibility is that the driver_manager has not yet loaded the correct policies for the ahci_drv or the config of the subinit and that it has updated them when I change the runtime config to run part_blk. However, I get no other errors, while I would have expected "no matching policy" or "no route" in that case.
I tried creating a clean run script with only the drivers_managed-pc package and part_blk inside it. It gives me the same error so it seems to be related to the drivers_managed-pc subsystem. When I run all those drivers directly on top of init, I do not get the error.
Can anyone explain what is going on?
Hi Boris,
The config snippet I added to sculpt.run just below the drivers init looks as follows (I copied it from default_fs_subinit.config except that my computer has an MBR partition scheme):
| <start name="part_blk" caps="100">|| || <resource name="RAM" quantum="10M"/>|| || <provides><service name="Block"/></provides>|| || <config use_gpt="no">|| || <policy label_prefix="vfs" writeable="yes" partition="1"/>|||| || </config>|| || <route>|| || <service name="Block"> <child name="drivers" label="default"/> </service>|| || <any-service> <parent/> </any-service>|| || </route>|| || </start>|
I tried giving part_blk more RAM, giving "drivers" more RAM, giving "drivers -> dynamic" more RAM and giving "drivers -> dynamic -> ahci_drv" more as well (by editing the driver_manager), but the error message persists with the same numbers as above.
Now I'm stuck on why this error occurs. One possibility is that the driver_manager has not yet loaded the correct policies for the ahci_drv or the config of the subinit and that it has updated them when I change the runtime config to run part_blk. However, I get no other errors, while I would have expected "no matching policy" or "no route" in that case.
I tried creating a clean run script with only the drivers_managed-pc package and part_blk inside it. It gives me the same error so it seems to be related to the drivers_managed-pc subsystem. When I run all those drivers directly on top of init, I do not get the error.
Can anyone explain what is going on?
I am not able to dive deep into it, but suspect that the session-creation error is caused by the label-rewriting route. Your start node relabels the block session as "default" whereas the service-forwarding policy of the `drivers -> dynamic` subsystem uses " default" (note the leading whitespace) [1] as policy selector, presuming that sessions are prefixed with the " -> " delimiter. This is the case when creating sessions from Sculpt's runtime subsystem in the unmodified scenario, but not anymore in your modified scenario.
Could you try relabeling your block session to "part_blk -> default" instead?
[1] https://github.com/genodelabs/genode/blob/master/repos/gems/src/app/driver_m...
Cheers Norman
On 15-05-18 08:08, Norman Feske wrote:
I am not able to dive deep into it, but suspect that the session-creation error is caused by the label-rewriting route. Your start node relabels the block session as "default" whereas the service-forwarding policy of the `drivers -> dynamic` subsystem uses " default" (note the leading whitespace) [1] as policy selector, presuming that sessions are prefixed with the " -> " delimiter. This is the case when creating sessions from Sculpt's runtime subsystem in the unmodified scenario, but not anymore in your modified scenario.
Could you try relabeling your block session to "part_blk -> default" instead?
I changed the config to the following:
<start name="part_blk" caps="100"> <resource name="RAM" quantum="50M"/> <provides><service name="Block"/></provides> <config use_gpt="no"> <policy label_prefix="vfs" writeable="yes" partition="1"/> <policy label_prefix="blk_crypt" writeable="yes" partition="6"/> </config> <route> <service name="Block"> <child name="drivers" label="part_blk -> default"/> </service> <any-service> <parent/> </any-service> </route> </start>
However, it still gives the exact same errors. Strangely, init still gives the warning: [init] Warning: part_blk: could not revert session RAM quota (service=Block cid=6 args='tx_buf_size=4194304, cap_quota=5, label="part_blk -> ", ram_quota=4207830, diag=0' state=SERVICE_DENIED ram_quota=4207830, cap_quota=5)
It looks like the label is not rewritten at all. changing "<service name="Block">" into "<service name="Block" label=""> does not do anything and the label inside the warning stays "part_blk -> ". Does this give you any clue?
Also, placing part_blk on another init which is not the runtime init also gives me these errors, even though the label is changed to "init -> part_blk -> ".
I had to subtract the quotas for part_blk from the vfs quotas. That solved the problem for me.
On Tue, May 15, 2018, 4:27 AM Boris Mulder boris.mulder@nlcsl.com wrote:
On 15-05-18 08:08, Norman Feske wrote:
I am not able to dive deep into it, but suspect that the session-creation error is caused by the label-rewriting route. Your start node relabels the block session as "default" whereas the service-forwarding policy of the `drivers -> dynamic` subsystem uses " default" (note the leading whitespace) [1] as policy selector, presuming that sessions are prefixed with the " -> " delimiter. This is the case when creating sessions from Sculpt's runtime subsystem in the unmodified scenario, but not anymore in your modified scenario.
Could you try relabeling your block session to "part_blk -> default" instead?
I changed the config to the following:
<start name="part_blk" caps="100"> <resource name="RAM" quantum="50M"/> <provides><service name="Block"/></provides> <config use_gpt="no"> <policy label_prefix="vfs" writeable="yes" partition="1"/> <policy label_prefix="blk_crypt" writeable="yes" partition="6"/> </config> <route> <service name="Block"> <child name="drivers" label="part_blk -> default"/> </service> <any-service> <parent/> </any-service> </route> </start>
However, it still gives the exact same errors. Strangely, init still gives the warning: [init] Warning: part_blk: could not revert session RAM quota (service=Block cid=6 args='tx_buf_size=4194304, cap_quota=5, label="part_blk -> ", ram_quota=4207830, diag=0' state=SERVICE_DENIED ram_quota=4207830, cap_quota=5)
It looks like the label is not rewritten at all. changing "<service name="Block">" into "<service name="Block" label=""> does not do anything and the label inside the warning stays "part_blk -> ". Does this give you any clue?
Also, placing part_blk on another init which is not the runtime init also gives me these errors, even though the label is changed to "init -> part_blk -> ".
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
This happens even without a VFS component using the block session. Just adding part_blk gives the error.
On 15-05-18 18:57, Nobody III wrote:
I had to subtract the quotas for part_blk from the vfs quotas. That solved the problem for me.
On Tue, May 15, 2018, 4:27 AM Boris Mulder boris.mulder@nlcsl.com wrote:
On 15-05-18 08:08, Norman Feske wrote:
I am not able to dive deep into it, but suspect that the session-creation error is caused by the label-rewriting route. Your start node relabels the block session as "default" whereas the service-forwarding policy of the `drivers -> dynamic` subsystem uses " default" (note the leading whitespace) [1] as policy selector, presuming that sessions are prefixed with the " -> " delimiter. This is the case when creating sessions from Sculpt's runtime subsystem in the unmodified scenario, but not anymore in your modified scenario.
Could you try relabeling your block session to "part_blk -> default" instead?
I changed the config to the following:
<start name="part_blk" caps="100"> <resource name="RAM" quantum="50M"/> <provides><service name="Block"/></provides> <config use_gpt="no"> <policy label_prefix="vfs" writeable="yes" partition="1"/> <policy label_prefix="blk_crypt" writeable="yes" partition="6"/> </config> <route> <service name="Block"> <child name="drivers" label="part_blk -> default"/> </service> <any-service> <parent/> </any-service> </route> </start>
However, it still gives the exact same errors. Strangely, init still gives the warning: [init] Warning: part_blk: could not revert session RAM quota (service=Block cid=6 args='tx_buf_size=4194304, cap_quota=5, label="part_blk -> ", ram_quota=4207830, diag=0' state=SERVICE_DENIED ram_quota=4207830, cap_quota=5)
It looks like the label is not rewritten at all. changing "<service name="Block">" into "<service name="Block" label=""> does not do anything and the label inside the warning stays "part_blk -> ". Does this give you any clue?
Also, placing part_blk on another init which is not the runtime init also gives me these errors, even though the label is changed to "init -> part_blk -> ".
--
Met vriendelijke groet / kind regards,
Boris Mulder
Cyber Security Labs B.V. | Gooimeer 6-31 | 1411 DD Naarden | The Netherlands +31 35 631 3253 (office)
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Boris Mulder -
Nobody III -
Norman Feske