GitLab

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

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

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

An EVL lock is now distinct from a hard lock in that it tracks and
disables preemption in the core when held.

Such spinlock may be useful when only EVL threads running out-of-band
can contend for the lock, to the exclusion of out-of-band IRQ
handlers. In this case, disabling preemption before attempting to grab
the lock may be substituted to disabling hard irqs.

There are gotchas when using such type of lock from the in-band
context, see comments in evl/lock.h.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Very short sections of code outside of any hot path are protected by
such lock. Therefore we would not generally benefit from the
preemption disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

For the most part, the gate lock is nested with a wait queue hard lock
- which requires hard irqs to be off - to access the protected
sections. Therefore we would not benefit in the common case from the
preemption disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

For the most part, a thread hard lock - which requires hard irqs to be
off - is nested with the mutex lock to access the protected
sections. Therefore we would not benefit in the common case from the
preemption disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Sleeping voluntarily with EVL preemption disabled is a bug. Add the
proper assertion to detect this.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Given the semantics of an evl_flag, disabling preemption manually
around the evl_raise_flag(to_flag) -> evl_wait_flag(from_flag)
sequence does not make sense.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The subscriber lock is shared between both execution stages, but
accessed from the in-band stage for the most part, which implies
disabling hard irqs while holding it. Meanwhile, out-of-band IRQs and
EVL threads may compete for the observable lock, which would require
hard irqs to be disabled while holding it.  Therefore we would not
generally benefit from the preemption disabling feature we are going
to add to the EVL-specific spinlock in any case. Make these hard locks
to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The data protected by the inbound (oob -> in-band traffic) buffer lock
is frequently accessed from the in-band stage by design, where hard
irqs should be disabled. Conversely, the out-of-band sections are
short enough to bear with interrupt-free execution. Therefore we would
not generally benefit from the preemption disabling feature we are
going to add to the EVL-specific spinlock. Make it a hard lock to
clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Out-of-band IRQs and EVL thread contexts would usually compete for
such lock, which would require hard irqs to be disabled while holding
it. Therefore we would not generally benefit from the preemption
disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The data protected by the file table lock is frequently accessed from
the in-band stage where holding it with hard irqs off is
required. Therefore we would not benefit in the common case from the
preemption disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Now that the inclusion hell is fixed with evl/wait.h, we may include
it into mm_info.h, for defining the ptsync barrier statically into the
out-of-band mm state.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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

Out-of-band IRQs and EVL thread contexts would usually compete for
such lock, which would require hard irqs to be disabled while holding
it. Therefore we would not generally benefit from the preemption
disabling feature we are going to add to the EVL-specific
spinlock. Make it a hard lock to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Out-of-band IRQs and EVL thread contexts may compete for such lock,
which would require hard irqs to be disabled while holding it.
Therefore we would not benefit from the preemption disabling feature
we are going to add to the EVL-specific spinlock. Make it a hard lock
to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Out-of-band IRQs and EVL thread contexts may compete for such lock,
which would require hard irqs to be disabled while holding it.
Therefore we would not benefit from the preemption disabling feature
we are going to add to the EVL-specific spinlock. Make it a hard lock
to clarify the intent.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We don't actually need to rely on the oob stall bit, provided hard
irqs are off in the deemed interrupt-free sections, because the latter
is sufficient as long as the code does not traverse a pipeline
synchronization point (sync_current_irq_stage()) while holding a lock,
which would be in and of itself a bug in the first place.

Remove the stall/unstall operations from the evl_spinlock
implementation, fixing the few locations which were still testing the
oob stall bit.

The oob stall bit is still set by Dovetail on entry to IRQ handlers,
which is ok: we will neither use nor affect it anymore, only relying
on hard disabled irqs.

This temporary alignment of the evl_spinlock on the hard spinlock is a
first step to revisit the lock types in the core, before the
evl_spinlock is changed again to manage the preemption count.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Checking the oob stall bit in __evl_enable_preempt() to block the
rescheduling is obsolete. It relates to a nested locking construct
which is long gone, when the evl_spinlock managed the preemption count
and the big lock was still in, i.e.:

lock_irqsave(&ugly_big_lock, flags)  /* stall bit raised */
	evl_spin_lock(&inner_lock);  /* +1 preempt */
	   wake_up_high_prio_thread();
	evl_spin_unlock(&inner_lock); /* -1 preempt == 0, NO schedule because stalled */
unlock_irqrestore(&ugly_big_lock, flags) /* stall bit restored */

This was a way to prevent a rescheduling to take place inadvertently
while holding the big lock.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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

This is a simple synchronization mechanism allowing an in-band caller
to pass a point in the code making sure that no out-of-band operations
which might traverse the same crossing are in flight.

Out-of-band callers delimit the danger zone by down-ing and up-ing the
barrier at the crossing, the in-band code should ask for passing the
crossing.

CAUTION: the caller must guarantee that evl_down_crossing() cannot be
invoked _after_ evl_pass_crossing() is entered for a given crossing.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Returns the current kthread descriptor or NULL if another thread
context is running. CAUTION: does not account for IRQ context.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We need more flexibility in the argument passed to the thread
function. Change for an opaque pointer passed to evl_run_kthread() and
variants instead of the current kthread descriptor.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

By convention, all thread-related calls which implicitly affect
current and therefore do not take any @thread parameter should use a
short-form name, such as evl_delay(), evl_sleep(). For this reason,
the following renames took place:

- evl_set_thread_period -> evl_set_period
- evl_wait_thread_period -> evl_wait_period
- evl_delay_thread -> evl_delay

In addition, complete the set of kthread-specific calls which are
based on the inner thread interface (this one working for user and
kernel threads indifferently):

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

This is an internal interface which should deal with ktime directly,
not timespec64. In addition, rename to set() in order to match the
converse short form read() call.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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

This is a tiny fix for the repeated evl/sched.h inclusion.
Signed-off-by: lio <liu.hailong6@zte.com.cn>

Trace event *evl_sched_attrs* calls TP_printk("%s") to out print the thread
name get by evl_element_name().

However, evl_element_name() may return NULL sometimes, and TP_printk(%s)
may cause some problems.

This patch will avoid this.
Signed-off-by: lio <carver4lio@163.com>

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>

Prioritization of timers in timer queues dates back to the Dark Ages
of Xenomai 2.x, when multiple time bases would co-exist in the core,
some of which representing date values as a count of periodic ticks.
In such a case, multiple timers might elapse on the very same tick,
hence the need for prioritizing them.

With a single time base indexing timers on absolute date values, which
are expressed as a 64bit monotonic count of nanoseconds, the
likelihood of observing identical trigger dates is very low.

Furthermore, the formerly defined priorities where assigned as
follows:

1) high priority to the per-thread periodic and resource timers
2) medium priority to the user-defined timers
3) low priority to the in-band tick emulation timer

It turns out that forcibly prioritizing 1) over 2) is at least
debatable, if not questionable: resource timers have no high priority
at all, they merely tick on the (unlikely) timeout condition. On the
other hand, user-defined timers may well deal with high priority
events only some EVL driver code may know about.

Finally, handling 3) is a fast operation on top of Dovetail, which is
already deferred internally whenever the timer management core detects
that some oob activity is running/pending.

So we may remove the logic handling the timer priority, only relying
on the trigger date for dispatching. This should save precious cycles
in the hot path without any actual downside.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

Align naming of the kthread termination-related calls on the in-band
counterparts. At this chance, further clarify the interface by having
evl_kthread_should_stop() explicitly return a boolean status.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

We cannot safely run the stage switching machinery while running in
NMI context.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

The trap_entry handler may expect hard irqs off on entry. It may
demote the current context to the in-band stage, may return with hard
irqs on.

The trap_exit handler only runs if trap_entry was called for the same
trap occurrence. It may expect hard irqs off on entry, may switch the
current context back to the oob stage. Must return with hard irqs
off. This departs from the previous implementation which allowed the
trap_exit handler to return with hard irqs on.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

This change first asserts that the FIFO class is the topmost
scheduling class by design.  From this point, we may check this class
upfront when looking for the next runnable thread to pick, without
going though the indirection of its .sched_pick handler.

This allows the compiler to fold most of the FIFO picking code into
the generic __pick_next_thread() routine, saving an indirect call.
This is nicer to the I-cache in all cases, and spares the cycles which
would otherwise be consumed by some vulnerability mitigation code like
retpolines.

On a highly cache-stressed i.mx6q, the worst case latency figures with
this change in dropped from about 5%.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

There is no user for this one.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>

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