[Xenomai-core] [PATCH] Add sigdebug unit test

[Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

We had two regressions in this code recently. So test all 6 possible
SIGDEBUG reasons, or 5 if the watchdog is not available.

Signed-off-by: Jan Kiszka <jan.kiszka@domain.hid>
---
 src/testsuite/unit/Makefile.am |   16 +++-
 src/testsuite/unit/sigdebug.c  |  233 ++++++++++++++++++++++++++++++++++++++++
 2 files changed, 248 insertions(+), 1 deletions(-)
 create mode 100644 src/testsuite/unit/sigdebug.c

diff --git a/src/testsuite/unit/Makefile.am b/src/testsuite/unit/Makefile.am
index 1bf5d8d..6e8203d 100644
--- a/src/testsuite/unit/Makefile.am
+++ b/src/testsuite/unit/Makefile.am
@@ -11,7 +11,8 @@ test_PROGRAMS = \
 	cond-torture-posix \
 	cond-torture-native \
 	check-vdso \
-	rtdm
+	rtdm \
+	sigdebug
 
 arith_SOURCES = arith.c arith-noinline.c arith-noinline.h
 
@@ -119,3 +120,16 @@ rtdm_LDADD = \
 	../../skins/native/libnative.la \
 	../../skins/common/libxenomai.la \
 	-lpthread -lrt -lm
+
+sigdebug_SOURCES = sigdebug.c
+
+sigdebug_CPPFLAGS = \
+	@XENO_USER_CFLAGS@ \
+	-I$(top_srcdir)/include
+
+sigdebug_LDFLAGS = @XENO_USER_LDFLAGS@
+
+sigdebug_LDADD = \
+	../../skins/native/libnative.la \
+	../../skins/common/libxenomai.la \
+	-lpthread -lm
diff --git a/src/testsuite/unit/sigdebug.c b/src/testsuite/unit/sigdebug.c
new file mode 100644
index 0000000..57d9beb
--- /dev/null
+++ b/src/testsuite/unit/sigdebug.c
@@ -0,0 +1,233 @@
+/*
+ * Functional testing of unwanted domain switch debugging mechanism.
+ *
+ * Copyright (C) Jan Kiszka  <jan.kiszka@domain.hid>
+ *
+ * Released under the terms of GPLv2.
+ */
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdbool.h>
+#include <string.h>
+#include <signal.h>
+#include <fcntl.h>
+#include <sys/mman.h>
+#include <pthread.h>
+#include <rtdk.h>
+#include <native/task.h>
+#include <native/mutex.h>
+#include <native/sem.h>
+#include <native/timer.h>
+
+#define WRITE_TEST_SIZE		(4*1024)
+
+unsigned int expected_reason;
+bool sigdebug_received;
+pthread_t rt_task_thread;
+RT_MUTEX prio_invert;
+RT_SEM send_signal;
+char *mem;
+FILE *wd;
+
+static void setup_checkdebug(unsigned int reason)
+{
+	sigdebug_received = false;
+	expected_reason = reason;
+}
+
+static void check_inner(const char *fn, int line, const char *msg,
+			int status, int expected)
+{
+	if (status == expected)
+		return;
+
+	rt_task_set_mode(T_WARNSW, 0, NULL);
+	rt_print_flush_buffers();
+	fprintf(stderr, "FAILURE %s:%d: %s returned %d instead of %d - %s\n",
+		fn, line, msg, status, expected, strerror(-status));
+	exit(EXIT_FAILURE);
+}
+
+static void check_sigdebug_inner(const char *fn, int line, const char *reason)
+{
+	if (sigdebug_received)
+		return;
+
+	rt_task_set_mode(T_WARNSW, 0, NULL);
+	rt_print_flush_buffers();
+	fprintf(stderr, "FAILURE %s:%d: no %s received\n", fn, line, reason);
+	exit(EXIT_FAILURE);
+}
+
+#define check(msg, status, expected) ({					\
+	int __status = status;						\
+	check_inner(__FUNCTION__, __LINE__, msg, __status, expected);	\
+	__status;							\
+})
+
+#define check_no_error(msg, status) ({					\
+	int __status = status;						\
+	check_inner(__FUNCTION__, __LINE__, msg,			\
+		    __status < 0 ? __status : 0, 0);			\
+	__status;							\
+})
+
+#define check_sigdebug_received(reason) do {				\
+	const char *__reason = reason;					\
+	check_sigdebug_inner(__FUNCTION__, __LINE__, __reason);		\
+} while (0)
+
+void rt_task_body(void *cookie)
+{
+	RTIME end;
+	int err;
+
+	rt_task_thread = pthread_self();
+
+	rt_printf("syscall\n");
+	setup_checkdebug(SIGDEBUG_MIGRATE_SYSCALL);
+	syscall(-1);
+	check_sigdebug_received("SIGDEBUG_MIGRATE_SYSCALL");
+
+	rt_printf("signal\n");
+	setup_checkdebug(SIGDEBUG_MIGRATE_SIGNAL);
+	err = rt_sem_v(&send_signal);
+	check_no_error("rt_sem_v", err);
+	rt_task_sleep(10000000LL);
+	check_sigdebug_received("SIGDEBUG_MIGRATE_SIGNAL");
+
+	rt_printf("relaxed mutex owner\n");
+	setup_checkdebug(SIGDEBUG_MIGRATE_PRIOINV);
+	err = rt_mutex_acquire(&prio_invert, TM_INFINITE);
+	check("rt_mutex_acquire", err, -EINTR);
+	check_sigdebug_received("SIGDEBUG_MIGRATE_PRIOINV");
+
+
+	rt_printf("page fault\n");
+	setup_checkdebug(SIGDEBUG_MIGRATE_FAULT);
+	rt_task_sleep(0);
+	*mem ^= 0xFF;
+	check_sigdebug_received("SIGDEBUG_MIGRATE_FAULT");
+
+	if (wd) {
+		rt_printf("watchdog\n");
+		rt_print_flush_buffers();
+		setup_checkdebug(SIGDEBUG_WATCHDOG);
+		end = rt_timer_tsc() + rt_timer_ns2tsc(2100000000ULL);
+		rt_task_sleep(0);
+		while (rt_timer_tsc() < end && !sigdebug_received)
+			/* busy loop */;
+		check_sigdebug_received("SIGDEBUG_WATCHDOG");
+	} else
+		rt_printf("note: watchdog not available\n");
+}
+
+void sigdebug_handler(int sig, siginfo_t *si, void *context)
+{
+	unsigned int reason = si->si_value.sival_int;
+
+	if (reason != expected_reason) {
+		rt_print_flush_buffers();
+		fprintf(stderr, "FAILURE: sigdebug_handler expected reason %d,"
+			" received %d\n", expected_reason, reason);
+		exit(EXIT_FAILURE);
+	}
+	sigdebug_received = true;
+}
+
+void dummy_handler(int sig, siginfo_t *si, void *context)
+{
+}
+
+int main(int argc, char **argv)
+{
+	char tempname[] = "/tmp/sigdebug-XXXXXX";
+	RT_TASK main_task, rt_task;
+	struct sigaction sa;
+	int old_wd_value;
+	int tmp_fd;
+	int err;
+
+	rt_print_auto_init(1);
+
+	wd = fopen("/sys/module/xeno_nucleus/parameters/watchdog_timeout",
+		   "w+");
+	if (wd) {
+		err = fscanf(wd, "%d", &old_wd_value);
+		check("get watchdog", err, 1);
+		err = fprintf(wd, "2");
+		check("set watchdog", err, 1);
+		fflush(wd);
+	}
+
+	sigemptyset(&sa.sa_mask);
+	sa.sa_sigaction = sigdebug_handler;
+	sa.sa_flags = SA_SIGINFO;
+	sigaction(SIGDEBUG, &sa, NULL);
+
+	sa.sa_sigaction = dummy_handler;
+	sigaction(SIGUSR1, &sa, NULL);
+
+	printf("mlockall\n");
+	setup_checkdebug(SIGDEBUG_NOMLOCK);
+	err = rt_task_shadow(&main_task, "main_task", 0, 0);
+	check("rt_task_shadow", err, -EINTR);
+	check_sigdebug_received("SIGDEBUG_NOMLOCK");
+
+	mlockall(MCL_CURRENT | MCL_FUTURE);
+
+	errno = 0;
+	tmp_fd = mkstemp(tempname);
+	check_no_error("mkstemp", -errno);
+	unlink(tempname);
+	check_no_error("unlink", -errno);
+	mem = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, tmp_fd, 0);
+	check_no_error("mmap", -errno);
+	err = write(tmp_fd, "X", 1);
+	check("write", err, 1);
+
+	err = rt_task_shadow(&main_task, "main_task", 0, 0);
+	check_no_error("rt_task_shadow", err);
+
+	err = rt_mutex_create(&prio_invert, "prio_invert");
+	check_no_error("rt_mutex_create", err);
+
+	err = rt_mutex_acquire(&prio_invert, TM_INFINITE);
+	check_no_error("rt_mutex_acquire", err);
+
+	err = rt_sem_create(&send_signal, "send_signal", 0, S_PRIO);
+	check_no_error("rt_sem_create", err);
+
+	err = rt_task_spawn(&rt_task, "rt_task", 0, 1, T_WARNSW | T_JOINABLE,
+			    rt_task_body, NULL);
+	check_no_error("rt_task_spawn", err);
+
+	err = rt_sem_p(&send_signal, TM_INFINITE);
+	check_no_error("rt_sem_signal", err);
+	pthread_kill(rt_task_thread, SIGUSR1);
+
+	rt_task_sleep(20000000);
+
+	err = rt_mutex_release(&prio_invert);
+	check_no_error("rt_mutex_release", err);
+
+	err = rt_task_join(&rt_task);
+	check_no_error("rt_task_join", err);
+
+	err = rt_mutex_delete(&prio_invert);
+	check_no_error("rt_mutex_delete", err);
+
+	err = rt_sem_delete(&send_signal);
+	check_no_error("rt_sem_delete", err);
+
+	if (wd) {
+		fprintf(wd, "%d", old_wd_value);
+		fclose(wd);
+	}
+
+	fprintf(stderr, "Test OK\n");
+
+	return 0;
+}
-- 
1.7.3.4

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 05:21 PM, Jan Kiszka wrote:
> We had two regressions in this code recently. So test all 6 possible
> SIGDEBUG reasons, or 5 if the watchdog is not available.

Ok for this test, with a few remarks:
- this is a regression test, so should go to
src/testsuite/regression(/native), and should be added to the
xeno-regression-test
- we already have a regression test for the watchdog called mayday.c,
which tests the second watchdog action, please merge mayday.c with
sigdebug.c (mayday.c also allows checking the disassembly of the code in
the mayday page, a nice feature)
- please make the watchdog test mandatory by default (adding a command
line option to skip it for instance), the test should fail if the
watchdog is not enabled, because otherwise, it will be easy to forget
testing this feature. The wathdog is enabled by default with xenomai 2.6
anyway.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>> We had two regressions in this code recently. So test all 6 possible
>> SIGDEBUG reasons, or 5 if the watchdog is not available.
> 
> Ok for this test, with a few remarks:
> - this is a regression test, so should go to
> src/testsuite/regression(/native), and should be added to the
> xeno-regression-test

What are unit test for (as they are defined here)? Looks a bit inconsistent.

> - we already have a regression test for the watchdog called mayday.c,
> which tests the second watchdog action, please merge mayday.c with
> sigdebug.c (mayday.c also allows checking the disassembly of the code in
> the mayday page, a nice feature)

It seems to have failed in that important last discipline. Need to check
why.

> - please make the watchdog test mandatory by default (adding a command
> line option to skip it for instance), the test should fail if the
> watchdog is not enabled, because otherwise, it will be easy to forget
> testing this feature. The wathdog is enabled by default with xenomai 2.6
> anyway.

OK.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-25 17:47, Jan Kiszka wrote:
> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>> We had two regressions in this code recently. So test all 6 possible
>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>
>> Ok for this test, with a few remarks:
>> - this is a regression test, so should go to
>> src/testsuite/regression(/native), and should be added to the
>> xeno-regression-test
> 
> What are unit test for (as they are defined here)? Looks a bit inconsistent.
> 
>> - we already have a regression test for the watchdog called mayday.c,
>> which tests the second watchdog action, please merge mayday.c with
>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>> the mayday page, a nice feature)
> 
> It seems to have failed in that important last discipline. Need to check
> why.

Because it didn't check the page content for correctness. But that's now
done via the new watchdog test. I can keep the debug output, but the
watchdog test of mayday looks obsolete to me. Am I missing something?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 05:52 PM, Jan Kiszka wrote:
> On 2012-01-25 17:47, Jan Kiszka wrote:
>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>> We had two regressions in this code recently. So test all 6 possible
>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>
>>> Ok for this test, with a few remarks:
>>> - this is a regression test, so should go to
>>> src/testsuite/regression(/native), and should be added to the
>>> xeno-regression-test
>>
>> What are unit test for (as they are defined here)? Looks a bit inconsistent.

I put under "regression" all the tests I have which corresponded to
things that failed one time or another in xenomai past. Maybe we could
move unit tests under regression.

>>
>>> - we already have a regression test for the watchdog called mayday.c,
>>> which tests the second watchdog action, please merge mayday.c with
>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>> the mayday page, a nice feature)
>>
>> It seems to have failed in that important last discipline. Need to check
>> why.
> 
> Because it didn't check the page content for correctness. But that's now
> done via the new watchdog test. I can keep the debug output, but the
> watchdog test of mayday looks obsolete to me. Am I missing something?

The watchdog does two things: it first sends a SIGDEBUG, then if the
application is still spinning, it sends a SIGSEGV. As far as I
understood, you test tests the first case, and mayday tests the second
case, so, I agree that mayday should be removed, but whatever it tests
should be integrated in the sigdebug test.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>
>>>> Ok for this test, with a few remarks:
>>>> - this is a regression test, so should go to
>>>> src/testsuite/regression(/native), and should be added to the
>>>> xeno-regression-test
>>>
>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
> 
> I put under "regression" all the tests I have which corresponded to
> things that failed one time or another in xenomai past. Maybe we could
> move unit tests under regression.
> 
>>>
>>>> - we already have a regression test for the watchdog called mayday.c,
>>>> which tests the second watchdog action, please merge mayday.c with
>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>> the mayday page, a nice feature)
>>>
>>> It seems to have failed in that important last discipline. Need to check
>>> why.
>>
>> Because it didn't check the page content for correctness. But that's now
>> done via the new watchdog test. I can keep the debug output, but the
>> watchdog test of mayday looks obsolete to me. Am I missing something?
> 
> The watchdog does two things: it first sends a SIGDEBUG, then if the
> application is still spinning, it sends a SIGSEGV. As far as I
> understood, you test tests the first case, and mayday tests the second
> case, so, I agree that mayday should be removed, but whatever it tests
> should be integrated in the sigdebug test.
> 

Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
test case actually specified a bug as correct behavior.

The fallback case is in fact killing the RT task as before. But I'm
unsure right now: will this leave the system always in a clean state
behind? The task killing of the watchdog is thought as a last resort to
keep the system analyzable, but I have a bad feeling if we want this in
a regular test case.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 06:10 PM, Jan Kiszka wrote:
> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>
>>>>> Ok for this test, with a few remarks:
>>>>> - this is a regression test, so should go to
>>>>> src/testsuite/regression(/native), and should be added to the
>>>>> xeno-regression-test
>>>>
>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>
>> I put under "regression" all the tests I have which corresponded to
>> things that failed one time or another in xenomai past. Maybe we could
>> move unit tests under regression.
>>
>>>>
>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>> the mayday page, a nice feature)
>>>>
>>>> It seems to have failed in that important last discipline. Need to check
>>>> why.
>>>
>>> Because it didn't check the page content for correctness. But that's now
>>> done via the new watchdog test. I can keep the debug output, but the
>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>
>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>> application is still spinning, it sends a SIGSEGV. As far as I
>> understood, you test tests the first case, and mayday tests the second
>> case, so, I agree that mayday should be removed, but whatever it tests
>> should be integrated in the sigdebug test.
>>
> 
> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
> test case actually specified a bug as correct behavior.
> 
> The fallback case is in fact killing the RT task as before. But I'm
> unsure right now: will this leave the system always in a clean state
> behind?

The test case being a test case and doing nothing particular, I do not
see what could go wrong. And if something goes wrong, then it needs fixing.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2654 bytes --]

On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>
>>>>>> Ok for this test, with a few remarks:
>>>>>> - this is a regression test, so should go to
>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>> xeno-regression-test
>>>>>
>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>
>>> I put under "regression" all the tests I have which corresponded to
>>> things that failed one time or another in xenomai past. Maybe we could
>>> move unit tests under regression.
>>>
>>>>>
>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>> the mayday page, a nice feature)
>>>>>
>>>>> It seems to have failed in that important last discipline. Need to check
>>>>> why.
>>>>
>>>> Because it didn't check the page content for correctness. But that's now
>>>> done via the new watchdog test. I can keep the debug output, but the
>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>
>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>> application is still spinning, it sends a SIGSEGV. As far as I
>>> understood, you test tests the first case, and mayday tests the second
>>> case, so, I agree that mayday should be removed, but whatever it tests
>>> should be integrated in the sigdebug test.
>>>
>>
>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>> test case actually specified a bug as correct behavior.
>>
>> The fallback case is in fact killing the RT task as before. But I'm
>> unsure right now: will this leave the system always in a clean state
>> behind?
> 
> The test case being a test case and doing nothing particular, I do not
> see what could go wrong. And if something goes wrong, then it needs fixing.

Well, if you kill a RT task while it's running in the kernel, you risk
inconsistent system states (held mutexex etc.). In this case the task is
supposed to spin in user space. If that is always safe, let's implement
the test.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/25/2012 06:10 PM, Jan Kiszka wrote:
> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>
>>>>> Ok for this test, with a few remarks:
>>>>> - this is a regression test, so should go to
>>>>> src/testsuite/regression(/native), and should be added to the
>>>>> xeno-regression-test
>>>>
>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>
>> I put under "regression" all the tests I have which corresponded to
>> things that failed one time or another in xenomai past. Maybe we could
>> move unit tests under regression.
>>
>>>>
>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>> the mayday page, a nice feature)
>>>>
>>>> It seems to have failed in that important last discipline. Need to check
>>>> why.
>>>
>>> Because it didn't check the page content for correctness. But that's now
>>> done via the new watchdog test. I can keep the debug output, but the
>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>
>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>> application is still spinning, it sends a SIGSEGV. As far as I
>> understood, you test tests the first case, and mayday tests the second
>> case, so, I agree that mayday should be removed, but whatever it tests
>> should be integrated in the sigdebug test.
>>
> 
> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
> test case actually specified a bug as correct behavior.

The bug was reproducible on ARM, for an other reason, hence the mistake.
Patch merged.

-- 
                                                                Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-25 19:05, Jan Kiszka wrote:
> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>
>>>>>>> Ok for this test, with a few remarks:
>>>>>>> - this is a regression test, so should go to
>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>> xeno-regression-test
>>>>>>
>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>
>>>> I put under "regression" all the tests I have which corresponded to
>>>> things that failed one time or another in xenomai past. Maybe we could
>>>> move unit tests under regression.
>>>>
>>>>>>
>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>> the mayday page, a nice feature)
>>>>>>
>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>> why.
>>>>>
>>>>> Because it didn't check the page content for correctness. But that's now
>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>
>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>> understood, you test tests the first case, and mayday tests the second
>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>> should be integrated in the sigdebug test.
>>>>
>>>
>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>> test case actually specified a bug as correct behavior.
>>>
>>> The fallback case is in fact killing the RT task as before. But I'm
>>> unsure right now: will this leave the system always in a clean state
>>> behind?
>>
>> The test case being a test case and doing nothing particular, I do not
>> see what could go wrong. And if something goes wrong, then it needs fixing.
> 
> Well, if you kill a RT task while it's running in the kernel, you risk
> inconsistent system states (held mutexex etc.). In this case the task is
> supposed to spin in user space. If that is always safe, let's implement
> the test.

Had a closer look: These days the two-stage killing is only useful to
catch endless loops in the kernel. User space tasks can't get around
being migrated on watchdog events, even when SIGDEBUG is ignored.

To trigger the enforced task termination without leaving any broken
states behind, there is one option: rt_task_spin. Surprisingly for me,
it actually spins in the kernel, thus triggers the second level if
waiting long enough. I wonder, though, if that behavior shouldn't be
improved, ie. the spinning loop be closed in user space - which would
take away that option again.

Thoughts?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Philippe Gerum]

On 01/26/2012 11:36 AM, Jan Kiszka wrote:
> On 2012-01-25 19:05, Jan Kiszka wrote:
>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>
>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>> - this is a regression test, so should go to
>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>> xeno-regression-test
>>>>>>>
>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>
>>>>> I put under "regression" all the tests I have which corresponded to
>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>> move unit tests under regression.
>>>>>
>>>>>>>
>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>> the mayday page, a nice feature)
>>>>>>>
>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>> why.
>>>>>>
>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>
>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>> understood, you test tests the first case, and mayday tests the second
>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>> should be integrated in the sigdebug test.
>>>>>
>>>>
>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>> test case actually specified a bug as correct behavior.
>>>>
>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>> unsure right now: will this leave the system always in a clean state
>>>> behind?
>>>
>>> The test case being a test case and doing nothing particular, I do not
>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>
>> Well, if you kill a RT task while it's running in the kernel, you risk
>> inconsistent system states (held mutexex etc.). In this case the task is
>> supposed to spin in user space. If that is always safe, let's implement
>> the test.
>
> Had a closer look: These days the two-stage killing is only useful to
> catch endless loops in the kernel. User space tasks can't get around
> being migrated on watchdog events, even when SIGDEBUG is ignored.
>
> To trigger the enforced task termination without leaving any broken
> states behind, there is one option: rt_task_spin. Surprisingly for me,
> it actually spins in the kernel, thus triggers the second level if
> waiting long enough. I wonder, though, if that behavior shouldn't be
> improved, ie. the spinning loop be closed in user space - which would
> take away that option again.
>
> Thoughts?
>

Tick-based timing is going to be the problem for determining the 
spinning delay, unless we expose it in the vdso on a per-skin basis, 
which won't be pretty.

> Jan
>


-- 
Philippe.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-26 12:20, Philippe Gerum wrote:
> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>> We had two regressions in this code recently. So test all 6
>>>>>>>>>> possible
>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>
>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>> xeno-regression-test
>>>>>>>>
>>>>>>>> What are unit test for (as they are defined here)? Looks a bit
>>>>>>>> inconsistent.
>>>>>>
>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>> things that failed one time or another in xenomai past. Maybe we
>>>>>> could
>>>>>> move unit tests under regression.
>>>>>>
>>>>>>>>
>>>>>>>>> - we already have a regression test for the watchdog called
>>>>>>>>> mayday.c,
>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of
>>>>>>>>> the code in
>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>
>>>>>>>> It seems to have failed in that important last discipline. Need
>>>>>>>> to check
>>>>>>>> why.
>>>>>>>
>>>>>>> Because it didn't check the page content for correctness. But
>>>>>>> that's now
>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing
>>>>>>> something?
>>>>>>
>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>> understood, you test tests the first case, and mayday tests the
>>>>>> second
>>>>>> case, so, I agree that mayday should be removed, but whatever it
>>>>>> tests
>>>>>> should be integrated in the sigdebug test.
>>>>>>
>>>>>
>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :)
>>>>> So the
>>>>> test case actually specified a bug as correct behavior.
>>>>>
>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>> unsure right now: will this leave the system always in a clean state
>>>>> behind?
>>>>
>>>> The test case being a test case and doing nothing particular, I do not
>>>> see what could go wrong. And if something goes wrong, then it needs
>>>> fixing.
>>>
>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>> inconsistent system states (held mutexex etc.). In this case the task is
>>> supposed to spin in user space. If that is always safe, let's implement
>>> the test.
>>
>> Had a closer look: These days the two-stage killing is only useful to
>> catch endless loops in the kernel. User space tasks can't get around
>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>
>> To trigger the enforced task termination without leaving any broken
>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>> it actually spins in the kernel, thus triggers the second level if
>> waiting long enough. I wonder, though, if that behavior shouldn't be
>> improved, ie. the spinning loop be closed in user space - which would
>> take away that option again.
>>
>> Thoughts?
>>
> 
> Tick-based timing is going to be the problem for determining the
> spinning delay, unless we expose it in the vdso on a per-skin basis,
> which won't be pretty.

I see. But we should possibly add some signal-pending || amok test to
that kernel loop. That would also kill my test design, but it makes
otherwise some sense I guess.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-26 13:56, Jan Kiszka wrote:
>>> To trigger the enforced task termination without leaving any broken
>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>> it actually spins in the kernel, thus triggers the second level if
>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>> improved, ie. the spinning loop be closed in user space - which would
>>> take away that option again.
>>>
>>> Thoughts?
>>>
>>
>> Tick-based timing is going to be the problem for determining the
>> spinning delay, unless we expose it in the vdso on a per-skin basis,
>> which won't be pretty.
> 
> I see. But we should possibly add some signal-pending || amok test to
> that kernel loop. That would also kill my test design, but it makes
> otherwise some sense I guess.

I'm thinking of a change like this:

diff --git a/ksrc/skins/native/syscall.c b/ksrc/skins/native/syscall.c
index acf0375..39204b4 100644
--- a/ksrc/skins/native/syscall.c
+++ b/ksrc/skins/native/syscall.c
@@ -1020,13 +1020,21 @@ static int __rt_timer_inquire(struct pt_regs *regs)
 
 static int __rt_timer_spin(struct pt_regs *regs)
 {
+	xnthread_t *thread = xnpod_current_thread();
+	struct task_struct *p = current;
+	RTIME etime;
 	RTIME ns;
 
 	if (__xn_safe_copy_from_user(&ns, (void __user *)__xn_reg_arg1(regs),
 				     sizeof(ns)))
 		return -EFAULT;
 
-	rt_timer_spin(ns);
+	etime = xnarch_get_cpu_tsc() + xnarch_ns_to_tsc(ns);
+	while ((SRTIME)(xnarch_get_cpu_tsc() - etime) < 0) {
+		if (signal_pending(p) || xnthread_amok_p(thread))
+			return -EINTR;
+		cpu_relax();
+	}
 
 	return 0;
 }

Regarding testability of the second watchdog state: We could add a
syscall to sigtest_module e.g which has the current rt_timer_spin
semantics.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 11:36 AM, Jan Kiszka wrote:
> On 2012-01-25 19:05, Jan Kiszka wrote:
>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>
>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>> - this is a regression test, so should go to
>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>> xeno-regression-test
>>>>>>>
>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>
>>>>> I put under "regression" all the tests I have which corresponded to
>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>> move unit tests under regression.
>>>>>
>>>>>>>
>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>> the mayday page, a nice feature)
>>>>>>>
>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>> why.
>>>>>>
>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>
>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>> understood, you test tests the first case, and mayday tests the second
>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>> should be integrated in the sigdebug test.
>>>>>
>>>>
>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>> test case actually specified a bug as correct behavior.
>>>>
>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>> unsure right now: will this leave the system always in a clean state
>>>> behind?
>>>
>>> The test case being a test case and doing nothing particular, I do not
>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>
>> Well, if you kill a RT task while it's running in the kernel, you risk
>> inconsistent system states (held mutexex etc.). In this case the task is
>> supposed to spin in user space. If that is always safe, let's implement
>> the test.
> 
> Had a closer look: These days the two-stage killing is only useful to
> catch endless loops in the kernel. User space tasks can't get around
> being migrated on watchdog events, even when SIGDEBUG is ignored.
> 
> To trigger the enforced task termination without leaving any broken
> states behind, there is one option: rt_task_spin. Surprisingly for me,
> it actually spins in the kernel, thus triggers the second level if
> waiting long enough. I wonder, though, if that behavior shouldn't be
> improved, ie. the spinning loop be closed in user space - which would
> take away that option again.
> 
> Thoughts?

You can also call in an infinite loop, a xenomais syscall which causes a
switch to primary mode, but fails.


-- 
					    Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>
>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>> xeno-regression-test
>>>>>>>>
>>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>>
>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>> move unit tests under regression.
>>>>>>
>>>>>>>>
>>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>
>>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>>> why.
>>>>>>>
>>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>
>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>> should be integrated in the sigdebug test.
>>>>>>
>>>>>
>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>>> test case actually specified a bug as correct behavior.
>>>>>
>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>> unsure right now: will this leave the system always in a clean state
>>>>> behind?
>>>>
>>>> The test case being a test case and doing nothing particular, I do not
>>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>>
>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>> inconsistent system states (held mutexex etc.). In this case the task is
>>> supposed to spin in user space. If that is always safe, let's implement
>>> the test.
>>
>> Had a closer look: These days the two-stage killing is only useful to
>> catch endless loops in the kernel. User space tasks can't get around
>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>
>> To trigger the enforced task termination without leaving any broken
>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>> it actually spins in the kernel, thus triggers the second level if
>> waiting long enough. I wonder, though, if that behavior shouldn't be
>> improved, ie. the spinning loop be closed in user space - which would
>> take away that option again.
>>
>> Thoughts?
> 
> You can also call in an infinite loop, a xenomais syscall which causes a
> switch to primary mode, but fails.

Nope, we would be migrated to secondary on xnthread_amok_p when
returning to user mode. We need a true kernel loop.

Jan.

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-26 15:36, Jan Kiszka wrote:
> Regarding testability of the second watchdog state: We could add a
> syscall to sigtest_module e.g which has the current rt_timer_spin
> semantics.

Do you think this makes sense? Or some other testing driver?
Then I would go that direction.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 04:06 PM, Jan Kiszka wrote:
> On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
>> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>>
>>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>>> xeno-regression-test
>>>>>>>>>
>>>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>>>
>>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>>> move unit tests under regression.
>>>>>>>
>>>>>>>>>
>>>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>>
>>>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>>>> why.
>>>>>>>>
>>>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>>
>>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>>> should be integrated in the sigdebug test.
>>>>>>>
>>>>>>
>>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>>>> test case actually specified a bug as correct behavior.
>>>>>>
>>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>>> unsure right now: will this leave the system always in a clean state
>>>>>> behind?
>>>>>
>>>>> The test case being a test case and doing nothing particular, I do not
>>>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>>>
>>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>>> inconsistent system states (held mutexex etc.). In this case the task is
>>>> supposed to spin in user space. If that is always safe, let's implement
>>>> the test.
>>>
>>> Had a closer look: These days the two-stage killing is only useful to
>>> catch endless loops in the kernel. User space tasks can't get around
>>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>>
>>> To trigger the enforced task termination without leaving any broken
>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>> it actually spins in the kernel, thus triggers the second level if
>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>> improved, ie. the spinning loop be closed in user space - which would
>>> take away that option again.
>>>
>>> Thoughts?
>>
>> You can also call in an infinite loop, a xenomais syscall which causes a
>> switch to primary mode, but fails.
> 
> Nope, we would be migrated to secondary on xnthread_amok_p when
> returning to user mode. We need a true kernel loop.

But the loop will continue, and the next call to the syscall will cause
the thread to re-switch to primary mode.

-- 
					    Gilles.

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Jan Kiszka]

On 2012-01-26 16:52, Gilles Chanteperdrix wrote:
> On 01/26/2012 04:06 PM, Jan Kiszka wrote:
>> On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
>>> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>>>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>>>
>>>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>>>> xeno-regression-test
>>>>>>>>>>
>>>>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>>>>
>>>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>>>> move unit tests under regression.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>>>
>>>>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>>>>> why.
>>>>>>>>>
>>>>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>>>
>>>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>>>> should be integrated in the sigdebug test.
>>>>>>>>
>>>>>>>
>>>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>>>>> test case actually specified a bug as correct behavior.
>>>>>>>
>>>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>>>> unsure right now: will this leave the system always in a clean state
>>>>>>> behind?
>>>>>>
>>>>>> The test case being a test case and doing nothing particular, I do not
>>>>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>>>>
>>>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>>>> inconsistent system states (held mutexex etc.). In this case the task is
>>>>> supposed to spin in user space. If that is always safe, let's implement
>>>>> the test.
>>>>
>>>> Had a closer look: These days the two-stage killing is only useful to
>>>> catch endless loops in the kernel. User space tasks can't get around
>>>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>>>
>>>> To trigger the enforced task termination without leaving any broken
>>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>>> it actually spins in the kernel, thus triggers the second level if
>>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>>> improved, ie. the spinning loop be closed in user space - which would
>>>> take away that option again.
>>>>
>>>> Thoughts?
>>>
>>> You can also call in an infinite loop, a xenomais syscall which causes a
>>> switch to primary mode, but fails.
>>
>> Nope, we would be migrated to secondary on xnthread_amok_p when
>> returning to user mode. We need a true kernel loop.
> 
> But the loop will continue, and the next call to the syscall will cause
> the thread to re-switch to primary mode.

But the "watchdog signal pending" flag will be cleared on each
migration, thus the watchdog will never enter the second stage.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Add sigdebug unit test

[Gilles Chanteperdrix]

On 01/26/2012 05:11 PM, Jan Kiszka wrote:
> On 2012-01-26 16:52, Gilles Chanteperdrix wrote:
>> On 01/26/2012 04:06 PM, Jan Kiszka wrote:
>>> On 2012-01-26 15:55, Gilles Chanteperdrix wrote:
>>>> On 01/26/2012 11:36 AM, Jan Kiszka wrote:
>>>>> On 2012-01-25 19:05, Jan Kiszka wrote:
>>>>>> On 2012-01-25 18:44, Gilles Chanteperdrix wrote:
>>>>>>> On 01/25/2012 06:10 PM, Jan Kiszka wrote:
>>>>>>>> On 2012-01-25 18:02, Gilles Chanteperdrix wrote:
>>>>>>>>> On 01/25/2012 05:52 PM, Jan Kiszka wrote:
>>>>>>>>>> On 2012-01-25 17:47, Jan Kiszka wrote:
>>>>>>>>>>> On 2012-01-25 17:35, Gilles Chanteperdrix wrote:
>>>>>>>>>>>> On 01/25/2012 05:21 PM, Jan Kiszka wrote:
>>>>>>>>>>>>> We had two regressions in this code recently. So test all 6 possible
>>>>>>>>>>>>> SIGDEBUG reasons, or 5 if the watchdog is not available.
>>>>>>>>>>>>
>>>>>>>>>>>> Ok for this test, with a few remarks:
>>>>>>>>>>>> - this is a regression test, so should go to
>>>>>>>>>>>> src/testsuite/regression(/native), and should be added to the
>>>>>>>>>>>> xeno-regression-test
>>>>>>>>>>>
>>>>>>>>>>> What are unit test for (as they are defined here)? Looks a bit inconsistent.
>>>>>>>>>
>>>>>>>>> I put under "regression" all the tests I have which corresponded to
>>>>>>>>> things that failed one time or another in xenomai past. Maybe we could
>>>>>>>>> move unit tests under regression.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> - we already have a regression test for the watchdog called mayday.c,
>>>>>>>>>>>> which tests the second watchdog action, please merge mayday.c with
>>>>>>>>>>>> sigdebug.c (mayday.c also allows checking the disassembly of the code in
>>>>>>>>>>>> the mayday page, a nice feature)
>>>>>>>>>>>
>>>>>>>>>>> It seems to have failed in that important last discipline. Need to check
>>>>>>>>>>> why.
>>>>>>>>>>
>>>>>>>>>> Because it didn't check the page content for correctness. But that's now
>>>>>>>>>> done via the new watchdog test. I can keep the debug output, but the
>>>>>>>>>> watchdog test of mayday looks obsolete to me. Am I missing something?
>>>>>>>>>
>>>>>>>>> The watchdog does two things: it first sends a SIGDEBUG, then if the
>>>>>>>>> application is still spinning, it sends a SIGSEGV. As far as I
>>>>>>>>> understood, you test tests the first case, and mayday tests the second
>>>>>>>>> case, so, I agree that mayday should be removed, but whatever it tests
>>>>>>>>> should be integrated in the sigdebug test.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Err... SIGSEGV is not a feature, it was the bug I fixed today. :) So the
>>>>>>>> test case actually specified a bug as correct behavior.
>>>>>>>>
>>>>>>>> The fallback case is in fact killing the RT task as before. But I'm
>>>>>>>> unsure right now: will this leave the system always in a clean state
>>>>>>>> behind?
>>>>>>>
>>>>>>> The test case being a test case and doing nothing particular, I do not
>>>>>>> see what could go wrong. And if something goes wrong, then it needs fixing.
>>>>>>
>>>>>> Well, if you kill a RT task while it's running in the kernel, you risk
>>>>>> inconsistent system states (held mutexex etc.). In this case the task is
>>>>>> supposed to spin in user space. If that is always safe, let's implement
>>>>>> the test.
>>>>>
>>>>> Had a closer look: These days the two-stage killing is only useful to
>>>>> catch endless loops in the kernel. User space tasks can't get around
>>>>> being migrated on watchdog events, even when SIGDEBUG is ignored.
>>>>>
>>>>> To trigger the enforced task termination without leaving any broken
>>>>> states behind, there is one option: rt_task_spin. Surprisingly for me,
>>>>> it actually spins in the kernel, thus triggers the second level if
>>>>> waiting long enough. I wonder, though, if that behavior shouldn't be
>>>>> improved, ie. the spinning loop be closed in user space - which would
>>>>> take away that option again.
>>>>>
>>>>> Thoughts?
>>>>
>>>> You can also call in an infinite loop, a xenomais syscall which causes a
>>>> switch to primary mode, but fails.
>>>
>>> Nope, we would be migrated to secondary on xnthread_amok_p when
>>> returning to user mode. We need a true kernel loop.
>>
>> But the loop will continue, and the next call to the syscall will cause
>> the thread to re-switch to primary mode.
> 
> But the "watchdog signal pending" flag will be cleared on each
> migration, thus the watchdog will never enter the second stage.

Ok, let us forget about this test of the second stage. Please add the
code which dumps the beginning of the mayday page to the test you
propose, we will merge this and remove mayday.c.

-- 
					    Gilles.