GitLab

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.

Unlike glibc, libcobalt may return zero as a valid timer id. Use a
threadobj status flag to figure out whether a periodic timer was set
for the thread, instead of testing periodic_timer for NULLness.

This fixes set_periodic/wait_period services which have been broken
since commit #73de42cc was merged.

We are running this section with cancellation deferred, so no
termination possible, thus nothing to clean up.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

The tracepoint array must be initialized early in essence, when no
real-time requirement exists yet. No need to pull such memory from the
real-time allocator, malloc is fine.

fusefs handlers are processed on behalf of the non-rt fusefs server
thread, which never holds rt locks by design while issuing memory
management calls (e.g. collect_wait_list()). So there is no need to
pull memory from the private real-time allocator which storage may be
limited, plain malloc is fine.

At this chance, add a few missing __STD() notations to existing free()
calls paired with __STD(malloc()).

Obstacks are grown from handlers called by the fusefs server thread,
which has no real-time requirement: malloc/free is fine for memory
management.

It's not really safe to allow a potentially modifying operation to be
canceled in the middle, just dropping the lock during rollback. Better
defer cancellation until the lock is dropped.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

This reverts commit 0f19393b.

No reason was given back then, and we there is the risk that this code
is used by prio-sensitive threads. Moreover, pvhash still used PI -
unless it is mapped on plain hash in case of !CONFIG_XENO_PSHARED.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Caller of threadobj_wait_period() should receive -EWOULDBLOCK if
threadobj_set_periodic() was not issued earlier.

Wait for the idling interface rework from I-pipe/4.14, which will
provide more information for determining whether Cobalt should be ok
with entering the target idle state.

As a result of this change, the original kernel behavior is restored
for all ipipe-4.9.y patches with respect to entering an idle state,
including for the releases lacking commits #89146106e8 or #8d3fa22c95.

This change only affects kernels built with CONFIG_CPU_IDLE enabled.

NOTE: XNIDLE is intentionally kept for future use in the Cobalt core.

The copy of the argument vector we build for preprocessing Xenomai
options must have argc + 1 cells, with argv[argc] set to NULL [1].

See http://xenomai.org/pipermail/xenomai/2018-March/038593.html.

[1] https://www.gnu.org/software/libc/manual/html_node/Program-Arguments.html

See http://xenomai.org/pipermail/xenomai/2018-March/038593.html

Timers may have specific CPU affinity requirements in that their
backing clock device might not beat on all available CPUs, but only on
a subset of them.

The CPU affinity of every timer bound to a particular thread has to be
tracked each time such timer is started, so that no core timer is
queued to a per-CPU list which won't receive any event from the
backing clock device.

Such tracking was missing for timerfd and POSIX timers, along with
internal timers running the sporadic scheduling policy.

At this chance, the timer affinity code was cleaned up by folding all
the affinity selection logic into a single call,
i.e. xntimer_set_affinity().

Since kernel 4.9, the pipeline code may ask us whether it would be
fine to enter the idle state on the current CPU, by mean of a probing
hook called ipipe_enter_idle_hook().

Provide this hook, considering that absence of outstanding timers
means idleness to us.

threadobj_unblock() simply does not work, dereferencing a NULL pointer
whenever it actually manages to unblock a thread waiting on a
synchronization object.

Calling syncobj_flush() on this object to wake up waiters zeroes the
wait_sobj field in the corresponding TCBs, so don't dereference
thobj->wait_sobj past this point.

Thread 1 "main" received signal SIGSEGV, Segmentation fault.
0x00007ffff79aeda0 in __syncobj_tag_unlocked (sobj=0x0) at include/copperplate/syncobj.h:100
100		assert(sobj->flags & SYNCOBJ_LOCKED);
(gdb) bt