hw: review signal semantics in comparison to the generic implementation #1781
Comments
chelmuth
added a commit
to chelmuth/genode
that referenced
this issue
Nov 18, 2015
chelmuth
changed the title
m-stein
added a commit
to m-stein/genode
that referenced
this issue
Nov 24, 2015
* Use Kernel::kill_signal/ack_signal only for demarshalling from UTCB * Use Signal_context::_destroy_lock and Kernel::kill_signal for destruction sync * Use Signal_receiver::block_for_signal/pending_signal to implement Signal_receiver::wait_for_signal * Move more stuff from specific signal/signal.cc to generic signal/common.cc * Use Signal_receiver::_contexts to find pending signals * Remove deprecated syscall Kernel::signal_pending Ref genodelabs#1738 Ref genodelabs#1781
|
There are some more open issues in the signal framework like the redundancy of Signal_context::_pending and Signal_context::_curr_signal (may both be raplaced by Signal_context::_num) or that Signal_context::submit/Signal_receiver::local_submit shouldn't be public but I would vote for opening separate issues for them. |
m-stein
added a commit
that referenced
this issue
Nov 24, 2015
* Use Kernel::kill_signal/ack_signal only for demarshalling from UTCB * Use Signal_context::_destroy_lock and Kernel::kill_signal for destruction sync * Use Signal_receiver::block_for_signal/pending_signal to implement Signal_receiver::wait_for_signal * Move more stuff from specific signal/signal.cc to generic signal/common.cc * Use Signal_receiver::_contexts to find pending signals * Remove deprecated syscall Kernel::signal_pending Ref #1738 Ref #1781
|
@m-stein should we close this issue or remove the fixed label? |
|
I forgot to add a "Fixed". Thanks. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the changes in #1738 esp. e32c19b, we revealed a gap between the generic signal-implementation semantics and the interpretation in base-hw. The generic implementation ensures correct reference counting in
Signal_contextaccording to the life time ofSignalobjects to support safe destruction of contexts. In base-hw, theSignallife time also triggersKernel::ack_signal()if the last reference to the linked context is dropped. Unfortunately, the genericSignal_contextobject stores the current pending signal as a member of typeSignal::Datawhich is just a plain data object not connected to the reference counting. In base-hw, we now have the challenge to demarshal the occuring signal from the UTCB inSignal_receiver::block_for_signal(), store it inSignal_context::_curr_signal, and only acknowledge at the kernel after is was retrieved from_curr_signalinSignal_receiver::pending_signal().From my investigation, the current issues with
run/nic_loopbackandrun/blk_cache(at least) on staging originate from the described gap. @m-stein please add any information a missed from our offline discussion yesterday.The text was updated successfully, but these errors were encountered: