On Mon, 2004-10-11 at 00:50, Philippe Gerum wrote:
> 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.
>
I think that something like this should do it even better:
--- pod.c~ 2004-10-07 22:31:52.000000000 +0200
+++ pod.c 2004-10-11 22:53:14.000000000 +0200
@@ -1156,6 +1156,17 @@
if (!testbits(thread->status,XNTHREAD_BLOCK_BITS))
{
+#ifdef __KERNEL__
+ /* If attempting to suspend a runnable (shadow) thread which
+ has received a Linux signal, just raise the break condition
+ and return immediately. */
+ if (testbits(thread->status,XNKICKED))
+ {
+ __setbits(thread->status,XNBREAK);
+ goto unlock_and_exit;
+ }
+#endif /* __KERNEL__ */
+
/* A newly created thread is not linked to the ready thread
queue yet. */
--
Philippe.
