Greg Gallagher authored Dec 05, 2017 and Philippe Gerum committed Dec 05, 2017

For the zynq platform (and possibly others in the future) we need to modify
gpio-core to request gpio pins before using them. The open() function will
now request a gpio and fail if it's already reserved. This should make
the pin request transparent to the user. The ability to request and release
pins is also available in an ioctrl message.  Tested on Microzed Zynq-7010
platform and the raspberry pi 2 board.

Greg Gallagher authored Dec 04, 2017 and Philippe Gerum committed Dec 05, 2017

split rtdm_fd_enter, move the functionality where we store the fd
until after the open() call succeeds.  Calls where open() fail a fd is
left in the tree even after the cleanup code is executed.  If this fd
number is used again we will fail the call to open until a different
fd is used.  This patch addresses this situation by not adding the fd
into the tree until open has succeeded and the fd is valid.

git repository hosting authored Dec 01, 2017 and Philippe Gerum committed Dec 01, 2017

Module: xenomai-jki
Branch: for-forge
Commit: dfec6f1f9448b4e207e36280a0e48923687a1cee
URL:    http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=dfec6f1f9448b4e207e36280a0e48923687a1cee



Author: Jan Kiszka <jan.kiszka@siemens.com>
Date:   Thu Nov 30 21:39:44 2017 +0100

cobalt/rtdm: Avoid dereferencing NULL device in __rtdm_dev_ioctl_core

File descriptors created by message queues or timerfds do not have
devices associated with them. Dereferencing that pointer prior to
checking if we have device fd in the first place is a recipe for
crashes.

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

TLSF's init_memory_pool() wants heaps to be larger than 4k on 64bit
architectures, due to the increased size of the meta-data compared to
their 32bit counterpart (struct tlsf).

Use 8k as the minimum heap size instead of PAGE_SIZE in the pshared
case, and make sure the main pool size amounts to at least 8k in the
process-private case, so that init_memory_pool() never fails in
heapobj_pkg_init_private().

Norbert Lange authored Nov 21, 2017 and Philippe Gerum committed Nov 22, 2017

the local debug variable has a name-clash with a identically named
function in arch/x86/include/asm/traps.h
also a macro guard apparently used an outdated name

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

This fixes a regression introduced by #4b4001c7.

Often reported as a failure to build Xenomai over Debian Stretch,
which ships with gcc6 built with --enable-default-pie, ld's -Ur option
as given by wrap-link.sh does not mix well with -pie which is
implicitly enabled, causing the linker to bail out on error.

Since this script eventually completes the link stage to produce a
fully resolved executable, collecting the ctors/dtors and resolving
all references from the partially linked object file is implied
anyway, making -Ur useless in stage2 at best.

For details, see:
http://xenomai.org/pipermail/xenomai/2017-October/037799.html
https://xenomai.org/pipermail/xenomai/2017-August/037648.html
http://www.xenomai.org/pipermail/xenomai/2017-May/037312.html

We need unwind tables to be precise at the instruction level, so they
can be used for accurate stack unwinding (e.g. backtrace()) from
asynchronous events like signals. Slackspot depends on this ability.

Failure to do so may cause applications to report incomplete
backtraces with glibc's backtrace(), or even crash over libunwind, see
http://xenomai.org/pipermail/xenomai/2017-October/037763.html

Enable -fasynchronous-unwind-tables for building the Xenomai libraries
and the user applications (via xeno-config --cflags).

Report and suggestion for a fix by Andreas Glatz
<andi.glatz@gmail.com>.

We do not want a syscall which is neither a Cobalt nor a Linux syscall
to trigger a switch to secondary mode when issued from primary
mode. Catch the situation early, returning ENOSYS.

__cobalt_monitor_wait() is racy wrt handling the pended state flag.
Given the threads A which consumes events from a monitor, and B which
produces them, the following situation may happen:

[A] __cobalt_monitor_wait()
[A]     release gate mutex
[B] fast acquire gate mutex
[B] grant/signal monitor
[B] fast release gate mutex (!MONITOR_PENDED, syscall-less)
[A]     raise MONITOR_PENDED flag
[A]     sleep_on(monitor)
        ... lost wake up signal, A keeps sleeping ...

To fix this, release the gate mutex only after the PENDED bit is
raised in the monitor state flags.

Jan Kiszka authored Oct 12, 2017 and Philippe Gerum committed Nov 14, 2017

None of these functions are called over interrupt context. Leaving the
critical sections interruptible can cause premature/double-unlock
scenarios and bug reports such as

[Xenomai] lock ffffffff81c56000 already unlocked on CPU #1
          last owner = kernel/xenomai/debug.c:74 (hash_symbol(), CPU #1)
 000000000000002f ffff88007dc8bb10 ffffffff8118ae8f ffffffff00000001
 0000000000000021 ffff88007f897fde ffff88007dc8bb50 ffffffff8118b266
 00000000000000f1 ffff88007dc8bd68 0000000000000006 ffff88007dc8bd40
Call Trace:
 [<ffffffff8118ae8f>] xnlock_dbg_release+0xdf/0xf0
 [<ffffffff8118b266>] hash_symbol+0x236/0x2d0
 [<ffffffff8118b668>] xndebug_trace_relax+0x118/0x450
 [<ffffffff811b8d50>] ? CoBaLt32emu_mmap+0xf0/0xf0
 [<ffffffff811b8dd7>] CoBaLt32emu_backtrace+0x87/0xb0
 [<ffffffff8100def6>] ? fpu__clear+0xd6/0x160
 [<ffffffff817b3691>] ? _raw_spin_unlock_irq+0x11/0x30
 [<ffffffff811ab1cc>] ipipe_syscall_hook+0x11c/0x3a0
 [<ffffffff8113d9bf>] __ipipe_notify_syscall+0xbf/0x180
 [<ffffffff810cd019>] ? __set_current_blocked+0x49/0x50
 [<ffffffff8113daab>] ipipe_handle_syscall+0x2b/0xb0
 [<ffffffff81001c9d>] do_fast_syscall_32+0xbd/0x220
 [<ffffffff817b64e2>] sysenter_flags_fixed+0x8/0x12

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

Charles Kiorpes authored Nov 03, 2017 and Philippe Gerum committed Nov 05, 2017

When CONFIG_XENO_PSHARED is set, heapobj_pkg_init_private() was causing unneeded pages to be locked into memory by performing a temporary allocation of the size of the entire memory pool.

This patch reduces the size of this temporary allocation to a single page when CONFIG_XENO_PSHARED is set.

Signed-off-by: Charles Kiorpes <ckiorpes@gmail.com>

Migrating a Cobalt thread to a different CPU _must_ go through the
regular set_cpus_allowed*() interface.

xnthread_migrate() cannot work with the 3.x architecture, and only
worked with pure kernel-based threads on 2.x.

Let's drop the confusing routine.

To maintain consistency between both Cobalt and host schedulers,
reflecting a thread migration to another CPU into the Cobalt scheduler
state must happen from secondary mode only, on behalf of the migrated
thread itself once it runs on the target CPU (*).

For this reason, handle_setaffinity_event() may NOT fix up
thread->sched immediately using the passive migration call for a
blocked thread.

Failing to ensure this may lead to the following scenario, with taskA
as the migrated thread, and taskB any other Cobalt thread:

CPU0(cobalt): suspend(taskA, XNRELAX)
CPU0(cobalt): suspend(taskB, ...)
CPU0(cobalt): enter_root(), next_task := <whatever>
...
CPU0(root): handle_setaffinity_event(taskA, CPU3)
      taskA->sched = xnsched_struct(CPU3)
CPU0(root): <relax epilogue code for taskA>
CPU0(root): resume(taskA, XNRELAX)
      enqueue(rq=CPU3), reschedule IPI to CPU3
CPU0(root): resume(taskB, ...)
CPU0(root): leave_root(), host_task := taskA
...
CPU0(cobalt): suspend(taskA)
CPU0(cobalt): enter_root(), next_task := host_task := taskA
CPU0(root??): <<<taskA execution>>> BROKEN
CPU3(cobalt): <taskA execution> via reschedule IPI

To sum up, we would end up with the migrated task running on both CPUs
in parallel, which would be, well, a problem.

To resync the Cobalt scheduler information, send a SIGSHADOW signal to
the migrated thread, asking it to switch back to primary mode from the
handler, at which point the interrupted syscall may be restarted. This
guarantees that check_affinity() is called, and fixups are done from
the proper context.

There is a cost: setting the affinity of a blocked thread may now
induce a delay for that target thread as well, since it has to make a
roundtrip between primary and secondary modes for handling the change
event. However, 1) there is no other safe way to handle such event, 2)
changing the CPU affinity of a remote real-time thread at random times
makes absolutely no sense latency-wise, anyway.

(*) This means that the Cobalt scheduler state regarding the
CPU information lags behind the host scheduler state until
the migrated thread switches back to primary mode
(i.e. task_cpu(p) != xnsched_cpu(xnthread_from_task(p)->sched)).
This is ok since Cobalt does not schedule such thread until then.

Christoph Muellner authored Oct 19, 2017 and Philippe Gerum committed Oct 19, 2017

create_pin_devices() consists of a loop, which creates a device file
for each GPIO of a GPIO chip. The loop's run condition is too strong,
which results in the last GPIO file not being created (e.g. gpio31 is
missing in case gc->ngpio is 32 and gc->base is 0).

This patch addresses this issue in branch 'next'.

Tested on a RK3399 (arm64).

Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com>

Some private Xenomai APIs are known to enter namespace conflicts with
C++ frameworks used by client real-time applications, e.g. Boost.

Instead of polluting the namespace even more by prefixing all private
definitions, hide them from the public scope by moving them to their
own separate headers, only the Xenomai C implementation should pull.

This commit only partially addresses the general issue, more work
remains to be done in this direction to fix all potential conflicts.

Antoine Hoarau authored Sep 28, 2017 and Philippe Gerum committed Sep 29, 2017

Prevents conflicts with libtbb that defines clz as an inline function and gets
replaced by those macros. Temporary fix waiting to move this code in private headers.

Boost (and maybe other frameworks) defines barrier() as a
synchonization method. Get away from further conflicts by referring
explicitly to a compiler barrier.

Henning Schild authored Aug 07, 2017 and Philippe Gerum committed Sep 15, 2017

Add basic error descriptions of two possible return values that where
not covered yet.

Signed-off-by: Henning Schild <henning.schild@siemens.com>

- firstly, keep short options in parsed vector
- secondly, disable getopt's parameter shuffling

nptl's pthread_condattr_setclock() routine does not accept
CLOCK_MONOTONIC_RAW, but only CLOCK_REALTIME or CLOCK_MONOTONIC.

For this reason, any API (e.g. libalchemy) would fail trying to set
condvar clocks to CLOCK_COPPERPLATE if --enable-clock-monotonic-raw
was passed to the configure script, as we originally mapped
CLOCK_COPPERPLATE over CLOCK_MONOTONIC_RAW in this case.

Since only Mercury might be affected by NTP adjustments to
CLOCK_MONOTONIC, not Cobalt, simply map CLOCK_COPPERPLATE over
CLOCK_MONOTONIC, as a general fix to the issue.