Restarting siblings vs. restarting nieces

[Martin Stein]

Hi Sid,

There is a pretty recent commit series on genodelabs/master for the HW
IPC mechanism that might be of interest for you:

1151706243 hw: rename functions of Ipc_node class signature
fd3c70ec5b hw: mark threads as dead in case of ipc violations
fc690f1c47 hw: re-work the ipc node's internal state machine

AFAIK, fc690f1c47 fixes at least two bugs with IPC on component exit. I
hope that helps you.

Cheers,
Martin

On 25.01.23 16:23, Sid Hussmann wrote:
> Dear Genodians,
> 
> I noticed a behavior that I would like to understand. Let's assume we
> have the following parent-child relationship of a sub-system, omitting
> some ancestors for simplicity:
> 
> ```
> .
> └── init
>    ├── fs
>    │   ├── init
>    │   │   └── rump
>    │   ├── fs_mgr
>    │   └── report_rom
>    ├── fs_client1
>    └── fs_client2
> ```
> 
> In this example, the config for the first `init` is written via the
> depot query/deploy mechanism. Thus, `fs`, `fs_client1`, and `fs_client2`
> are pkg archives. The `runtime` file from pkg archive `fs` contains a
> management component `fs_mgr` that generates an `init` config which
> starts a `vfs` server with a `rump` plugin within that `init`.
> For context, we use the `fs_mgr` to instrument it to start `fsck` or
> `mkfs` depending on its configuration. But that's not relevant right now.
> 
> Let's also assume the routing is valid so that `fs_client1` and
> `fs_client2` are up and running, and they both consume the `File_system`
> session provided by `rump`.
> 
> Now to my observation:
> 
> When I restart `fs` by incrementing its version attribute in the deploy
> file, `fs`, `fs_client1`, and `fs_client2` all get restarted. That is
> what I would expect.
> 
> However, the behavior is different when I instrument the `fs_mgr` to
> restart `rump`. Most of the time, both `fs_client1` and `fs_client2`
> don't seem to notice.
> 
> Is this behavior by design? Is `init` designed to behave differently
> regarding client/server dependency when siblings get restarted vs. when
> a niece is restarted?
> 
> Is there a way to instrument `fs_mgr` to write an `init` config, so that
> `fs_client1` and `fs_client2` get restarted?
> 
> Granted, I observed this in a more complex scenario. I once had the
> following errors when restarting `rump` on `arm_v8a/base-hw`:
> 
> ```
> Kernel: init -> init -> fs_client1 -> ep: cannot send to unknown recipient
> ...
> Kernel: Cpu 0 error: re-entered lock. Kernel exception?!
> ```
> 
> Would it make sense for me to create a simplified scenario of it to dig
> into this behavior further?
> 
> Kind regards,
> Sid
> 
> 
> _______________________________________________
> Genode users mailing list
> users at lists.genode.org
> https://lists.genode.org/listinfo/users
>