GitLab

Fixing a longstanding misnomer: this flag is really about sending
unicast notifications as opposed to broadcasting events to all
observers.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We might be writing past the array collecting the active events, if
more events were ready in the event group than we had entries in the
return array. Fix the test detecting the end of this array.

This bug caused a stack smashing in the poll-multiple test.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

When a proxy device is taking control of a (real) broadcast device, we
have to:

- remove the real device from the clockevents_list
- keep that device ticking, i.e. no shutdown

Fix tick_check_new_device() accordingly.
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We have to fix up the TSS with the proper I/O bitmap settings in
arch_dovetail_switch_finish() when the incoming Dovetail-enabled task
is about to re-enter user mode.

This fixes an application crash observed when such a task would rely
on iopl() to raise its I/O permissions then block, relinquishing the
CPU to another task invalidating them, before the former eventually
resumes in user mode.

See https://xenomai.org/pipermail/xenomai/2022-March/047451.html

.
Reported-by: Richard Weinberger <richard.weinberger@gmail.com>
Tested-by: Richard Weinberger <richard.weinberger@gmail.com>
Reviewed-by: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Dovetail does not cope well with paravirtualization ATM, which is why
XEN depends on !IRQ_PIPELINE. For the same reason, there is no point
in adding any IRQ trampoline code for XEN_PVHVM.

Also, prevent CONFIG_HYPERV from being built if interrupt pipeling is
enabled, since the former depends on paravirtualization too.
Reported-by: Hongzhan Chen <hongzhan.chen@intel.com>
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

GENERIC_CLOCKSOURCE_VDSO is currently available for ARM and ARM64, but
some drivers which can export their clocksource via the vDSO can still
be built for unsupported architectures like x86.

Use a weak reverse dependency logic for vDSO-exported clocksources,
enabling GENERIC_CLOCKSOURCE_VDSO only when building for the proper
architecture.
Suggested-by: Hongzhan Chen <hongzhan.chen@intel.com>
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This fixes a wreckage introduced during a recent merge.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This is not fixing a bug, but rather prevents GCC from complaining
about incompatible types in casts between function pointers, which are
nevertheless correct runtime-wise.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Jan Kiszka authored Feb 18, 2022 and Philippe Gerum committed Apr 23, 2022

Due to an earlier check for running_oob(), this path will always be
entered in-band. So the hooks are pointless.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

COW-disabling for a dovetailed process does not depend on the pinning
status of the source mm considered by copy_present_page(). Decouple
both checks, which fixes the following kernel splat on fork() from a
dovetailed task:

[   18.376448] ------------[ cut here ]------------
[   18.376915] kernel BUG at mm/rmap.c:1049!
[   18.377259] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI IRQ_PIPELINE
[   18.377262] CPU: 0 PID: 121 Comm: smokey Not tainted 5.15.9+ #12
[   18.377264] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014
[   18.377265] IRQ stage: Linux
[   18.377266] RIP: 0010:__page_set_anon_rmap+0x59/0x70
[   18.377271] Code: c9 74 22 48 83 c0 01 48 89 43 18 f6 47 52 40 75 1b 48 2b 17 48 c1 ea 0c 48 03 97 98 00 00 00 48 89 53 20 5b c3 48 8b 00 eb d9 <0f> 0b 48 89 d6 e8 ad c6 01 00 48 89 c2 eb e6 0f 1f 84 00 00 00 00
[   18.377273] RSP: 0018:ffffc90000b0bb50 EFLAGS: 00010246
[   18.377275] RAX: 0000000000000000 RBX: 0000000...

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Jan Kiszka authored Nov 12, 2021 and Philippe Gerum committed Apr 23, 2022

__secure_computing, called by syscall_trace_enter, returns -1 when a
call should be skipped. We must avoid that this is interpreted as
EXIT_SYSCALL_OOB in the dovetail case.

Fixes, e.g., crashes of Chrome in sandbox mode.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

These changes aim at enabling support for both the legacy and
prctl-based syscall formats by the same kernel, without affecting the
syscall handling logic in the companion cores which still depend on
the former. CONFIG_DOVETAIL_LEGACY_SYSCALL_RANGE should be turned on
by such cores in order to enable the legacy call format.

If CONFIG_DOVETAIL_LEGACY_SYSCALL_RANGE is set, we assume the
companion core may not handle the new prctl-based call format, but
expects the __OOB_SYSCALL_BIT to be set directly into the syscall code
register instead, defining its own syscall range.

In this case, prctl() requests with an oob signature might be received
by the oob syscall handler, but these should always be handled from
the in-band stage, regardless of the call arguments. To this end, the
oob syscall handler is allowed to ask for the request to be propagated
to the peer in-band handler, which would then decide to either handle
the request locally, or pass it down in turn to the regular syscall
handler. This is a rare case, when prctl-based syscalls are not
accepted by the companion core, but some application would issue
prctl() calls matching the oob signature (i.e. prctl(option |
__OOB_SYSCALL_BIT, ...)), denoting either a misconfiguration, or a
broken application.

If CONFIG_DOVETAIL_LEGACY_SYSCALL_RANGE is unset, every oob syscall
must be folded into a prctl() request, with the __OOB_SYSCALL_BIT set
into the option argument.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Receiving in-band __NR_prctl syscalls via their oob handler may
confuse some companion cores still using the legacy call form (i.e. nr
| __OOB_SYSCALL_BIT).

Dig a little deeper into prctl() call args in order to pass oob call
forms exclusively to handle_oob_syscall().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Receiving in-band __NR_prctl syscalls via their oob handler may
confuse some companion cores still using the legacy call form (i.e. nr
| __OOB_SYSCALL_BIT).

Dig a little deeper into prctl() call args in order to pass oob call
forms exclusively to handle_oob_syscall().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Jan Kiszka authored Nov 08, 2021 and Philippe Gerum committed Apr 23, 2022

This code is already under CONFIG_SMP: The comment got it right, not yet
the implementation. Only affects the pipeline-off case.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>

Florian Bezdeka authored Nov 08, 2021 and Philippe Gerum committed Apr 23, 2022

Whenever an IRQ was handled for a vector being NULL or in one of the
error states the interrupt was not acknowledged at the APIC. That can
happen if a vector is cleaned up by one of the device drivers while
there is still one IRQ in flight.

This has two effects:
  - If the affected vector is re-assigned later, it does not work, the
    IRQ never makes its way to the CPU
  - Interrupts with lower priority are no longer delivered to the CPU

The problem was observed on a quite big Intel XEON machine where some
vectors / irqs were temporary used and cleaned up and re-assigned
later.
Signed-off-by: Florian Bezdeka <florian.bezdeka@siemens.com>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Handle both the legacy and prctl-based call forms available from
Dovetail, i.e.:

syscall(sys_evl_<op> | __OOB_SYSCALL_BIT, ...) /* old form */
syscall(__NR_prctl, sys_evl_<op> | __OOB_SYSCALL, ...) /* new form */

With this change, we gain out-of-the-box support for Valgrind since
applications can now emit EVL system calls wrapped in prctl()
requests, which are readily recognized by the instrumentation
framework.

As a result, the ABI number is bumped to #27.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Updating tsk->comm requires holding the task lock, along with
propagating the change to a few subsystems (e.g. trace, perf). Use
set_task_comm() to update such field instead of open coding the change
in a half baked way. Also, make sure such change is forwarded to the
process event connector.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Make sure the percpu timer IPI is disabled on all CPUs before release.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Several factors may cause the active watchpoint count to be lesser
than the poll table size as a result of collecting events:

- a stale file descriptor is encountered (-EBADF)
- bad user memory is written to while copying back evl_poll_event (-EFAULT)
- the user event set has fewer entries than the ready set (> 0)

In all of these cases, we may end up watching fewer files than the
total amount of items in the poll table, in which case poll_context.nr
is larger than the actual number of active watchpoints.

For this reason, clear_wait() cannot iterate over poll_context.nr
items, but should rather consider the active watchpoints only. To this
end, introduce poll_context.active which is set by collect_events()
appropriately.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This bug would cause the last watchpoint from the poll table to be
left unexpectedly detached, which in turn would break clear_wait().

At this chance, clarify some naming in evl_drop_poll_table().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This code lays the groundwork for an out-of-band network stack.  It
currently provides basic AF_PACKET support (SOCK_RAW only) from the
out-of-band stage, reusing the regular NIC drivers unmodified for
dealing with the hardware. Therefore, the stack has NO end-to-end
real-time property just yet.

The next steps will address:

- a kernel API for making regular NIC drivers oob-capable.

- a mechanism for the out-of-band core to learn the routing
  information dynamically produced by the in-band stack.

- support for UDP/AF_INET.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Align on the in-band definition of a ktime value which cannot
represent a sensible timeout.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Knowing which synchronization object a thread sleeps on may be quite
helpful while debugging. Export this information as a thread device
attribute to /sys. Add it to the relevant tracepoints as well.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>