GitLab

If we change the quota value of thread group, we should take its already
consumed time during the current cycle into account. So far, we refilled
the budget blindly, which could have given the group an uncontrolled
"peak".

This commit first update the run_budget_ns of an active group and kills
its limit timer. Then it refills run_budget_ns only with the remaining
budget of the current cycle, taking the new quota as limit.

Accumulated credits are still dropped - not worth to deal with their
complexity in this scenario.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

This is to avoid namespace conflicts (e.g.: with Clang's arm_acle.h)
Signed-off-by: Giulio Moro <giuliomoro@yahoo.it>
[Jan: back-ported to 3.0.x]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The rtps tools reads the /proc/xenomai/sched/acct file but didn't
take the xsc field in account and failed to display some Xenomai
threads. This patch adds the missing field when rtps reads a line.
Signed-off-by: Christophe Blaess <christophe.blaess@logilin.fr>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The CPU affinity mask in __base_setup_data.cpu_affinity - which may be
set by --cpu-affinity - is conventionally checked by applications for
determining which CPUs are usable for real-time duties.

Over Cobalt, we need to make sure that such mask reflects the set of
CPUs available for running real-time threads as defined by the core
(i.e. /proc/xenomai/affinity), in absence of --cpu-affinity
setting.

Otherwise, some applications like switchest looking at an empty
affinity mask may wrongly assume that all CPUs are available for
running RT threads, leading to a failure when manually pinning such
thread to an invalid (non-RT) CPU.

With current Cobalt core and I-pipe releases not fixed for gracefully
handling invalid domain migration requests over a non-RT CPU, such a
failure may trigger a kernel panic.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

If xnregistry_enter in mq_open fails, the new entry will not be added to
cobalt_mqq. But the cleanup path taken afterwards will nevertheless try
to remove it from there. That will cause a crash because the mq->link is
uninitialized. Fix that by initializing it as list head so that list
removal becomes harmless, even when the entry is not on any list..
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Otherwise, weird results could be seen when the second wraps, leading
to t1.nsec < t2.nsec, e.g.:

T: 0 ( 1107) P:98 I:1000 C:1886710 Min:      0 Act:    4 Avg:2147483647 Max:      -1
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

xnsched_realtime_cpus is a misnomer defining the set of CPUs which may
handle timer events.

cobalt_cpu_affinity is a subset of xnsched_realtime_cpus which defines
which CPU(s) may run Cobalt threads.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

cobalt_cpu_affinity defines the CPU set which may run Cobalt threads,
which is a subset of xnsched_realtime_cpus. I.e. we may handle IRQs
over CPUs which do not run threads.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Attempting to migrate to the head domain while running on a CPU which
is not in part of the real-time set is a bug, and must be detected by
the core.

Furthermore, for this detection to work, the I-pipe must not BUG()
unconditionally when failing to schedule out such thread in
__ipipe_migrate_head(), but rather let the real-time core handle the
situation (i.e. Xenomai in xnthread_harden()).

Until both changes are in place, running a thread issuing a real-time
call over a non-RT CPU would trigger a BUG() assertion, e.g.:

With kernel parameter "xenomai.supported_cpus=2", running:

$ switchtest --cpu-affinity=0

would lead to:

[   11.681486] kernel BUG at kernel/sched/core.c:5816!
[   11.686343] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Make sure people do run the cyclictest the way it is intended to with
Xenomai (i.e. using Xenomai's rt scheduler...).

Also, detect and bail out upon spurious relaxes in dual kernel mode,
so that latency results are dismissed as they should until the bug is
fixed.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

This overwrote the pointer itself - and more. Long pending bugs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

asm/uaccess.h is an arch-local, partial header which may cause build
issues if included directly.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

4.14 is always eager, unfortunately we will need a few ifdefs inside the
eager fpu support as well.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
[Jan: converted C++-style comment]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER
accordingly.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Upstream 4.14 switched to purely eager fpu switching. That was
backported to 4.4 and 4.9. This commit makes cobalt able to deal whith
the changed kernel behaviour.
This commit takes care of 4.9 to begin with.

Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
implementations. The new implementation is much simpler than the old
one. We basically only deal with the odd case where Xenomai preempts
Linux in a kernel-fpu context.
In a regular Linux that can never happen and if it happens we need to
make sure to get things into a consistent state. We have to make
"current" as not owning the fpu anymore and allow others to use
in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the
rest.
Signed-off-by: Henning Schild <henning.schild@siemens.com>
[Jan: converted C++-style comments]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Testing debug switches using '#if XENO_DEBUG(<feat>)' may confuse the
build system's dependency tracker, breaking the build, or even
producing a non-bootable kernel in extreme cases. Typically, turning
on/off the lock debugging code - usually in absence of any other
change - may cause the following error to pop up at the link stage:
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

For external projects wanting to use RTnet with its special
features like RTnet IOCTLs it is necessary to provide the API
headers in the Xenomai installation directory.

We need to free pending signals that have been allocated via
cobalt_signal_alloc() on thread destruction, or we will run out of them
quickly.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The NULL-test is currently performed also in case we assign a
pre-checked value from the master to base_addr. This is harmless, but
the compiler correctly complains about the misaligned code block - or
the missing braces.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

We missed to create and copy the shadow into userspace in case a
preexisting semaphore was opened in process that didn't created it. Was
biting us in pshared setups, but also when the previous owner died
before destroying a named semaphore.
Reported-by: Paal Tamas <paal_to@freemail.hu>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Properly destroy the semaphore in case we cannot allocate a
cobalt_named_sem struct.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Partially revert #8e606e68, keeping registry_add_dir/file() routines
free from Cobalt mode switches, a property which some applications
might assume when creating specific rt objects (e.g. Alchemy's
mutexes, condvars).

When --enable-pshared is passed, we currently have no mean to specify
the size of the private heap managed by TLSF.

Until this issue is fixed, increase the fixed size of the private heap
to 64k, so that running OOM in the few remaining code spots calling
the pvmalloc* API becomes unlikely.

This way a dlclose() will not unmap the libs memory anymore. A real
dlclose() will not work anyways because we lack destructors for all the
stuff we initialize in setup_descriptor->init().
Signed-off-by: Henning Schild <henning.schild@siemens.com>

The intention of another binary and fork/exec was to have a binary is
not a xenoami-binary already, to actually test dlopen.
Unfortunately a copy-paste mistake in Makefile.am resulted in dlopentest
being a xenomai application already. Therefore the dlopens tested
something they where not supposed to.

Change Makefile.am to make dlopentest a truly non-xenomai binary. And
change what it is testing accordingly. We do not support dlclose so do
not test it anymore.
Signed-off-by: Henning Schild <henning.schild@siemens.com>

In fact we would need real destructors for all setup_descriptor s. Stop
pretending that we know how to dlclose or destruct.

This reverts commit 5511e760.

Signed-off-by: Norbert Lange <norbert.lange@andritz.com>

This is a severe bug which would cause an already reserved page range
to be returned twice in specific situations depending on the bitmap
contents at the time of the second allocation.

This reverts commit 5b0c3677 which was
wrong and fortunately did not survive the upcoming memcheck tests.

Increase the number of RTDM devices that are allowed to be registered to 4096 to allow gpio drivers with higher pin numbers to be able to register in rtdm space.