On Sun, 2004-10-10 at 23:54, Marc Kleine-Budde wrote: > On Sun, Oct 10, 2004 at 10:52:16PM +0200, Philippe Gerum wrote: > > > > > How does the delivery of linux signals work with fusion thread? > > > > I see - But what happens to hardened linux tasks who just working in > > > RT-userspace? A reschedule 'only'? > > > > ---------------<xnshadow_kick_process>--------------------- > > > if (thread == thread->sched->runthread) > > > xnsched_set_resched(thread->sched); > > > [...] > > > xnpod_schedule(); > > > ----------------------------------------------------------- > > > > They don't get the XNKICKED flag set...AFAICS in the nucleus scheduler > > > there isn't a test for signals_pending() - At least no test for > > > linux-signals, only for xenomai or are both connected in a way I've > > > overlooked? When will the threads in this state be relaxed? > > > No, they are not connected. Linux signals can be handled over the Linux > > context only. The flow of control is as follows: > > > o Linux sends a signal to a Linux task mapped to a shadow thread; so the > > current CPU must be operating in relaxed or idle mode. > > Bar works hardend in RT-Userspace, higher priozied foo gets unblocked > due to the end of a timer, foo's code contains a kill(<pid-of-bar>, 2), > foo gets migrated into linux-domain during delivery of the syscall, > signals is delivered to bar, resulting in this: > > > o xnshadow_kick_process() intercepts the call to signal_wake_up(), and > > wakes up the associated shadow thread if it is currently blocked in > > hardened mode on a nucleus wait channel. In such a case, the shadow is > > forcibly unblocked. > > bar is not blocked... > What happens then? >
As far as my brain is effective at this hour, bar resumes at some point in time, XNKICKED is set and signal_pending() are raised for it, the next time it will exit the nanokernel after a syscall, it will be relaxed by request_syscall_restart() but ERESTARTSYS won't be set (which is ok, since no syscall was interrupted), and the signal will be processed when returning to Linux. The potential flaw is that we should check for the XNKICKED condition on entry from xnshadow_realtime_sysentry() too, and not only upon exit, because if bar goes sleeping, we'd have to wait for its wakeup for processing the signal condition. > > o the shadow resumes execution in hardened mode, and the interrupted > > blocking service checks for the XNBREAK condition raised by the > > unblocking service (xnpod_unblock_thread()), and returns -EINTR. > > bar's shadow continues eventually in hardend mode, no XNBREAK due to no > blocking, no -EINTR... > > > o given that the interrupted system call was issued by a user-space RT > > thread (otherwise it's a non-issue), then the awaken thread returns to > > the syscall demultiplexer in shadow.c, and sets up the syscall restart > > condition appropriately when applicable (i.e. signal_pending() and > > -EINTR returned by the blocking syscall). At this point, the running > > shadow is forcibly relaxed, so that Linux gets back in control. > > bar was not in a systemcall...where is the signal_pending() check for > this case? > > > o the Xenomai syscall (which has been interrupted) then returns through > > the normal Linux syscall exit path, which handles the pending signal, > > fires the handler or runs the default action. > > Marc -- Philippe.
