[Xenomai] Resuming nanosleep & Co. after ignored signals

[Xenomai] Resuming nanosleep & Co. after ignored signals

[Jan Kiszka]

Hi,

originally, this effect was only reported for debugged applications, but
I think it affects more:

clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
they were interrupted by signal while sleeping. OK. But what if that
signal was SIGSTOP, maybe even related to ptrace? Right now the function
just bails out, and applications behave differently from native Linux.
There we resume the sleep transparently if the signal is not delivered
to some handler (or actually terminates the process).

How could we model this properly with Xenomai? And could there be more
services affected than clock_nanosleep?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Gilles Chanteperdrix]

On Tue, May 10, 2016 at 05:57:05PM +0200, Jan Kiszka wrote:
> Hi,
> 
> originally, this effect was only reported for debugged applications, but
> I think it affects more:
> 
> clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
> they were interrupted by signal while sleeping. OK. But what if that
> signal was SIGSTOP, maybe even related to ptrace? Right now the function
> just bails out, and applications behave differently from native Linux.
> There we resume the sleep transparently if the signal is not delivered
> to some handler (or actually terminates the process).
> 
> How could we model this properly with Xenomai? And could there be more
> services affected than clock_nanosleep?

I was going to say, this is unspecified by POSIX, but actually it
is:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html

The relevant sentence is:
"the clock_nanosleep() function shall cause the current thread to be
suspended from execution until either the time interval specified by
the rqtp argument has elapsed, or a signal is delivered to the
calling thread and its action is to invoke a signal-catching
function"

Clearly, the action of SIGSTOP is not "a signal-catching function",
and the sleep should not appear to have been interrupted.

Just saying, I have no idea whatsoever on how to get this working.

Regards.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Jan Kiszka]

On 2016-05-10 18:08, Gilles Chanteperdrix wrote:
> On Tue, May 10, 2016 at 05:57:05PM +0200, Jan Kiszka wrote:
>> Hi,
>>
>> originally, this effect was only reported for debugged applications, but
>> I think it affects more:
>>
>> clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
>> they were interrupted by signal while sleeping. OK. But what if that
>> signal was SIGSTOP, maybe even related to ptrace? Right now the function
>> just bails out, and applications behave differently from native Linux.
>> There we resume the sleep transparently if the signal is not delivered
>> to some handler (or actually terminates the process).
>>
>> How could we model this properly with Xenomai? And could there be more
>> services affected than clock_nanosleep?
> 
> I was going to say, this is unspecified by POSIX, but actually it
> is:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
> 
> The relevant sentence is:
> "the clock_nanosleep() function shall cause the current thread to be
> suspended from execution until either the time interval specified by
> the rqtp argument has elapsed, or a signal is delivered to the
> calling thread and its action is to invoke a signal-catching
> function"
> 
> Clearly, the action of SIGSTOP is not "a signal-catching function",
> and the sleep should not appear to have been interrupted.
> 
> Just saying, I have no idea whatsoever on how to get this working.

It's at least not trivial: The kernel has per-thread restart blocks
where it pushes the timer state of an interrupted relative
clock_nanosleep so that the restarted syscall will not restart the timer
at 0.

And then we still need to differentiate between those two signal types
(delivered to handler vs. internally processed).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Gilles Chanteperdrix]

On Tue, May 10, 2016 at 06:21:17PM +0200, Jan Kiszka wrote:
> On 2016-05-10 18:08, Gilles Chanteperdrix wrote:
> > On Tue, May 10, 2016 at 05:57:05PM +0200, Jan Kiszka wrote:
> >> Hi,
> >>
> >> originally, this effect was only reported for debugged applications, but
> >> I think it affects more:
> >>
> >> clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
> >> they were interrupted by signal while sleeping. OK. But what if that
> >> signal was SIGSTOP, maybe even related to ptrace? Right now the function
> >> just bails out, and applications behave differently from native Linux.
> >> There we resume the sleep transparently if the signal is not delivered
> >> to some handler (or actually terminates the process).
> >>
> >> How could we model this properly with Xenomai? And could there be more
> >> services affected than clock_nanosleep?
> > 
> > I was going to say, this is unspecified by POSIX, but actually it
> > is:
> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
> > 
> > The relevant sentence is:
> > "the clock_nanosleep() function shall cause the current thread to be
> > suspended from execution until either the time interval specified by
> > the rqtp argument has elapsed, or a signal is delivered to the
> > calling thread and its action is to invoke a signal-catching
> > function"
> > 
> > Clearly, the action of SIGSTOP is not "a signal-catching function",
> > and the sleep should not appear to have been interrupted.
> > 
> > Just saying, I have no idea whatsoever on how to get this working.
> 
> It's at least not trivial: The kernel has per-thread restart blocks
> where it pushes the timer state of an interrupted relative
> clock_nanosleep so that the restarted syscall will not restart the timer
> at 0.
> 
> And then we still need to differentiate between those two signal types
> (delivered to handler vs. internally processed).

Since we will return from the xenomai syscall in secondary mode, we
could conceivably go through the plain Linux syscall epilogue with
the restart block, using a specific restart block which piggy backs
into xenomai kernel. I wonder if xenomai syscall returning in
secondary mode do not go through the plain Linux syscall epilogue
already, actually.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Philippe Gerum]

On 05/11/2016 08:05 AM, Gilles Chanteperdrix wrote:
> On Tue, May 10, 2016 at 06:21:17PM +0200, Jan Kiszka wrote:
>> On 2016-05-10 18:08, Gilles Chanteperdrix wrote:
>>> On Tue, May 10, 2016 at 05:57:05PM +0200, Jan Kiszka wrote:
>>>> Hi,
>>>>
>>>> originally, this effect was only reported for debugged applications, but
>>>> I think it affects more:
>>>>
>>>> clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
>>>> they were interrupted by signal while sleeping. OK. But what if that
>>>> signal was SIGSTOP, maybe even related to ptrace? Right now the function
>>>> just bails out, and applications behave differently from native Linux.
>>>> There we resume the sleep transparently if the signal is not delivered
>>>> to some handler (or actually terminates the process).
>>>>
>>>> How could we model this properly with Xenomai? And could there be more
>>>> services affected than clock_nanosleep?
>>>
>>> I was going to say, this is unspecified by POSIX, but actually it
>>> is:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
>>>
>>> The relevant sentence is:
>>> "the clock_nanosleep() function shall cause the current thread to be
>>> suspended from execution until either the time interval specified by
>>> the rqtp argument has elapsed, or a signal is delivered to the
>>> calling thread and its action is to invoke a signal-catching
>>> function"
>>>
>>> Clearly, the action of SIGSTOP is not "a signal-catching function",
>>> and the sleep should not appear to have been interrupted.
>>>
>>> Just saying, I have no idea whatsoever on how to get this working.
>>
>> It's at least not trivial: The kernel has per-thread restart blocks
>> where it pushes the timer state of an interrupted relative
>> clock_nanosleep so that the restarted syscall will not restart the timer
>> at 0.
>>
>> And then we still need to differentiate between those two signal types
>> (delivered to handler vs. internally processed).
> 
> Since we will return from the xenomai syscall in secondary mode, we
> could conceivably go through the plain Linux syscall epilogue with
> the restart block, using a specific restart block which piggy backs
> into xenomai kernel. I wonder if xenomai syscall returning in
> secondary mode do not go through the plain Linux syscall epilogue
> already, actually.
> 

Correct, it does.

-- 
Philippe.

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Jan Kiszka]

On 2016-05-11 09:17, Philippe Gerum wrote:
> On 05/11/2016 08:05 AM, Gilles Chanteperdrix wrote:
>> On Tue, May 10, 2016 at 06:21:17PM +0200, Jan Kiszka wrote:
>>> On 2016-05-10 18:08, Gilles Chanteperdrix wrote:
>>>> On Tue, May 10, 2016 at 05:57:05PM +0200, Jan Kiszka wrote:
>>>>> Hi,
>>>>>
>>>>> originally, this effect was only reported for debugged applications, but
>>>>> I think it affects more:
>>>>>
>>>>> clock_nanosleep (as well as nanosleep and sleep) should return -EINTR if
>>>>> they were interrupted by signal while sleeping. OK. But what if that
>>>>> signal was SIGSTOP, maybe even related to ptrace? Right now the function
>>>>> just bails out, and applications behave differently from native Linux.
>>>>> There we resume the sleep transparently if the signal is not delivered
>>>>> to some handler (or actually terminates the process).
>>>>>
>>>>> How could we model this properly with Xenomai? And could there be more
>>>>> services affected than clock_nanosleep?
>>>>
>>>> I was going to say, this is unspecified by POSIX, but actually it
>>>> is:
>>>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
>>>>
>>>> The relevant sentence is:
>>>> "the clock_nanosleep() function shall cause the current thread to be
>>>> suspended from execution until either the time interval specified by
>>>> the rqtp argument has elapsed, or a signal is delivered to the
>>>> calling thread and its action is to invoke a signal-catching
>>>> function"
>>>>
>>>> Clearly, the action of SIGSTOP is not "a signal-catching function",
>>>> and the sleep should not appear to have been interrupted.
>>>>
>>>> Just saying, I have no idea whatsoever on how to get this working.
>>>
>>> It's at least not trivial: The kernel has per-thread restart blocks
>>> where it pushes the timer state of an interrupted relative
>>> clock_nanosleep so that the restarted syscall will not restart the timer
>>> at 0.
>>>
>>> And then we still need to differentiate between those two signal types
>>> (delivered to handler vs. internally processed).
>>
>> Since we will return from the xenomai syscall in secondary mode, we
>> could conceivably go through the plain Linux syscall epilogue with
>> the restart block, using a specific restart block which piggy backs
>> into xenomai kernel. I wonder if xenomai syscall returning in
>> secondary mode do not go through the plain Linux syscall epilogue
>> already, actually.
>>
> 
> Correct, it does.
> 

I was thinking along these lines already, but it is not straightforward.
The problems that we cannot directly use the restart mechanism. It would
make userspace issue the restart syscall, a Linux one, but we need to
migrate in that syscall to primary mode again. That, to my
understanding, can only be done from within the syscall hook because
only then we ensure running the correct syscall return path.

But we may reuse at least Linux' mechanism to decide if the syscall
should be restarted or not by initializing and then evaluating
restart_block.fn in our nanosleep syscall. I will play with that today.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] Resuming nanosleep & Co. after ignored signals

[Jan Kiszka]

On 2016-05-11 09:25, Jan Kiszka wrote:
> On 2016-05-11 09:17, Philippe Gerum wrote:
>> On 05/11/2016 08:05 AM, Gilles Chanteperdrix wrote:
>>> Since we will return from the xenomai syscall in secondary mode, we
>>> could conceivably go through the plain Linux syscall epilogue with
>>> the restart block, using a specific restart block which piggy backs
>>> into xenomai kernel. I wonder if xenomai syscall returning in
>>> secondary mode do not go through the plain Linux syscall epilogue
>>> already, actually.
>>>
>>
>> Correct, it does.
>>
> 
> I was thinking along these lines already, but it is not straightforward.
> The problems that we cannot directly use the restart mechanism. It would
> make userspace issue the restart syscall, a Linux one, but we need to
> migrate in that syscall to primary mode again. That, to my
> understanding, can only be done from within the syscall hook because
> only then we ensure running the correct syscall return path.
> 
> But we may reuse at least Linux' mechanism to decide if the syscall
> should be restarted or not by initializing and then evaluating
> restart_block.fn in our nanosleep syscall. I will play with that today.
> 

Here is the outcome which seems to work but is a bit hacky by relying on
Linux to set restart_block.fn to do_no_restart_syscall if it delivered a
signal (and by reusing the nanosleep.expires field). Feedback welcome
if / how this could be turned into an upstream feature.

Jan

diff --git a/include/cobalt/uapi/kernel/thread.h b/include/cobalt/uapi/kernel/thread.h
index 8d26f16..409e75d 100644
--- a/include/cobalt/uapi/kernel/thread.h
+++ b/include/cobalt/uapi/kernel/thread.h
@@ -77,6 +77,7 @@
 
 #define XNMOVED   0x00000001 /**< CPU migration in primary mode occurred */
 #define XNLBALERT 0x00000002 /**< Scheduler lock break alert (SIGDEBUG sent) */
+#define XNRESTART 0x00000004
 
 /** @} */
 
diff --git a/kernel/cobalt/posix/clock.c b/kernel/cobalt/posix/clock.c
index b51cb4c..a54a516 100644
--- a/kernel/cobalt/posix/clock.c
+++ b/kernel/cobalt/posix/clock.c
@@ -237,7 +237,7 @@ int __cobalt_clock_nanosleep(clockid_t clock_id, int flags,
 			     struct timespec *rmt)
 {
 	struct xnthread *cur;
-	xnsticks_t rem;
+	xnsticks_t timeout, rem;
 	int ret = 0;
 	spl_t s;
 
@@ -261,10 +261,37 @@ int __cobalt_clock_nanosleep(clockid_t clock_id, int flags,
 
 	xnlock_get_irqsave(&nklock, s);
 
-	xnthread_suspend(cur, XNDELAY, ts2ns(rqt) + 1,
+	if (xnthread_test_localinfo(cur, XNLBALERT)) {
+		xnthread_clear_localinfo(cur, XNLBALERT);
+
+		if (current->restart_block.fn != NULL) {
+			xnlock_put_irqrestore(&nklock, s);
+
+			if (rmt)
+				ns2ts(rmt, rem > 1 ? rem : 0);
+			return -EINTR;
+		}
+
+		timeout = current->restart_block.nanosleep.expires;
+	} else
+		timeout = ts2ns(rqt);
+
+	xnthread_suspend(cur, XNDELAY, timeout + 1,
 			 clock_flag(flags, clock_id), NULL);
 
 	if (xnthread_test_info(cur, XNBREAK)) {
+		if (flags == 0 && signal_pending(current)) {
+			xnthread_set_localinfo(cur, XNLBALERT);
+
+			current->restart_block.fn = NULL;
+			current->restart_block.nanosleep.expires =
+				xntimer_get_timeout_stopped(&cur->rtimer);
+
+			xnlock_put_irqrestore(&nklock, s);
+
+			return -ERESTARTSYS;
+		}
+
 		if (flags == 0 && rmt) {
 			rem = xntimer_get_timeout_stopped(&cur->rtimer);
 			xnlock_put_irqrestore(&nklock, s);
@@ -280,7 +307,7 @@ int __cobalt_clock_nanosleep(clockid_t clock_id, int flags,
 	return ret;
 }
 
-COBALT_SYSCALL(clock_nanosleep, nonrestartable,
+COBALT_SYSCALL(clock_nanosleep, primary,
 	       (clockid_t clock_id, int flags,
 		const struct timespec __user *u_rqt,
 		struct timespec __user *u_rmt))


-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux