It is necessary to delay setting lock_count = 0 because an unlocking thread
maybe swapped out when it calls adjust_owner_prio(). If the thread that starts
running sees lock_count = 0 it will successfully acquire the mutex even though
it is not fully unlocked yet.
Fixes#11798.
Signed-off-by: Nicolás Bértolo <nicolasbertolo@gmail.com>
The comment explaining why _IntLibInit was being invoked was left in
place after the invocation itself was removed. Remove it too.
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
The function that checks if an object is valid is essentially a boolean
function. Just changing its return type to reflect it.
MISRA-C rule 14.4
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This allows for workqueues to be started in user mode.
No additional kernel objects or system calls are defined
other than starting the workqueue in user mode; for
permission purposes the embedded queue and thread objects
are sufficient.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
k_work and k_work_q are not kernel objects, nor will they
be. k_work_q contains some kernel objects which are tracked
independently.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
There were many platforms where this function was doing nothing. Just
merging its functionality with _PrepC function.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
System must not set the clock expiry via backdoor as it may
effect in unbound time drift of all scheduled timeouts.
Fixes: #11502
Signed-off-by: Pawel Dunaj <pawel.dunaj@nordicsemi.no>
System Power Management is only supported in Tickless Idle mode.
This patch modifies Kconfig dependencies to ensure System Power
Management option selects Tickless Idle one.
Fixes: #11046
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
The call to z_clock_set_timeout() was being made outside the timeout
lock, which can race against other contexts setting sooner-expiring
timeouts.
Also add a long comment to one spot (timeslicing) where this call is
made outside the timeout spinlock (inside the scheduler lock) and why
this is OK.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add implementation for k_msgq_peek() which is similar to k_msgq_get()
except the message is not deleted from the queue.
Signed-off-by: Sathish Kuttan <sathish.k.kuttan@intel.com>
If we just had the kernel's implementation, we could
just move this to lib/, but possible arch-specific
implementations dictate that we just make this a
syscall.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We aren't going to allow any user mode access to the
k_mem_slab APIs, but in some cases (specifically in the
case of the I2S subsystem) we need to allow user mode
to assign a memory slab to a particular driver.
This will let us verfiy (in supervisor mode) that a provided
k_mem_slab pointer is really a k_mem_slab, and know its
initialization state, and have permissions assigned to it.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This commit optimizes the process of checking that the
added partitions in a mem_domain are sane. It places the
sane_partition checking inside the loop of adding the
partitions in the mem_domain, so that the checkings are
not performed twice, and no partition is checked against
itself.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
This commit fixes the calculations of the partition ending
addresses in two places in the code, according to:
<last> = <start> + <size> - 1. We also rename 'end' to 'last'
to stress that we calculate the last address in the partition.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
User mode may need to use this API to get a handle on
devices by name, expose as a system call. We impose
a maximum name length as the system call handler needs
to make a copy of the string passed in from user mode.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
If this function is itself interrupted by a timeslice event, the
slicing state can be corrupted. Just re-use the scheduler lock
instead of using a new spinlock; this is a low-latency function that
won't deadlock. Found by inspection.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a TICKLESS_CAPABLE kconfig variable which is used by the kernel to
select tickless mode's default automatically on drivers that support
it (rather than having to set the default per-board). Select it from
the ARM SysTick and Intel HPET drivers.
Also remove the old qemu_cortex_m3 default settings which this
replaces.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Some places are using the same tag identifier with different types.
This is a MISRA-C violation and makes the code less readable.
MISRA-C rule 5.7
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
k_poll_signal was being used by both, struct and function. Besides
this being extremely error prone it is also a MISRA-C violation.
Changing the function to contain a verb, since it performs an action
and the struct will be a noun. This pattern must be formalized and
followed and across the project.
MISRA-C rules 5.7 and 5.9
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
There was an struct and a variable called _kernel. This is error prone
and a MISRA-C violation. It is changing the struct to have a unique
identifier.
MISRA-C rule 5.8
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
According with MISRA-C an object should be defined in a block scope if
it is used in a single function.
MISRA-C rule 8.9
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This is not violating any MISRA-C rule, though, it seems to be
triggering a false (rule 9.1) positive in some static analysis
tools. Nevertheless, it is more readable declare all variables in the
same scope together.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
There is a struct and a macro called _ready_q, this is error
prone. Just removing it.
MISRA-C rule 5.4
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The tracing variable in alert.c was declared by default. This
should have been declared only when CONFIG_OBJECT_TRACING is set.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This patch fixes few issues in queue.c. This patch also changes
the return type of k_queue_alloc_append and k_queue_alloc_prepend
from int to s32_t.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This commit introduces k_sleep() return value, which provides
information about actual sleep time. If the returned value is
not-zero, the thread slept shorter than requested, which is
only possible if the thread has been woken up by k_wakeup() call.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Fixing a few minor typo fixes in kernel/mem_domain.c
and the respective documentation section.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Fix a compile warning if we build using int types defined to match the
compiler. We get the following warnings:
kernel/msg_q.c: In function ‘_impl_k_msgq_alloc_init’:
kernel/msg_q.c:75:9: warning: passing argument 3 of ‘__builtin_umul_overflow’ from incompatible pointer type [-Wincompatible-pointer-types]
(u32_t *)&total_size)) {
^
kernel/msg_q.c:75:9: note: expected ‘unsigned int *’ but argument is of type ‘u32_t * {aka long unsigned int *}’
__builtin_umul_overflow expects to be passed unsigned int for all its
arguments, so cast to that instead of u32_t.
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Previously, a generic "workqueue" name was used, but there're few
workqueues in a typical Zephyr setup, and it wasn't possible to
distinguish them.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
In _pend_current_thread the argument key is always a unsigned
interger type and this function forces it to become a signed
interger. This is a dangerous behavior and cant be trusted to
work as expected.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Duh: "remove()" is a POSIX symbol, and on at least some platforms
stdio.h can be included here out of platform headers causing a name
collision.
Fixes#10669's direct issue, though the broader issue of how to choose
names for statics remains controversial.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This API shouldn't take a int type but instead it should take
u32_t. This argument has to be similar to irq_lock() and
irq_unlock().
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
In tickless mode, not all elapsed ticks may have been announced yet,
so future z_time_slice() calls will include "extra" ticks that we have
to account for when setting up the slice count.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Our funny convention holds that passing ticks==1 to _add_timeout()
means "at the next tick". But that means that 1, 0, and all negative
numbers are expected to behave the same. In ticked mode, that's fine
because it will, after all, expire at the next tick.
But in tickless, the next announcement may be for several ticks, and
that zero will appear to expire "before" the next tick in the
consumption loop.
Make sure all "next tick" expirations look the same.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When fetching the next timeout to expire, the value is relative to the
last announced tick, so you subtract the timer-provided elapsed time
to get the true delta from "now". When adding a new timeout, you
*have* a value relative to now, so you compute the delta vs. the last
announced tick by adding the elapsed() time. Duh.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was wrong in subtle ways. In tickless mode it's possible to get
an announcement for multiple ticks at a time and have multiple
callbacks to execute that were technically scheduled at different
times. We want to fix the current tick at the value represented by
the currently-executing callback's EXPIRATION (even if we missed it!),
so that any new timeouts it sets (c.f. a k_timer period) happen at the
right point, in phase with the expected series. In single-tick mode
the code ends up the same always, so the bug wasn't visible.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The previous comment correctly and carefully explained why the 64 bit
value in curr_tick doesn't require locking when reading only the low
32 bits.
It completely missed the fact that the calculation of elapsed time and
the read of curr_tick ABSOLUTELY DO require locking, because the
former is expressed in terms of the latter. This was always bug, even
in the old code, but never witnessed because we ran so little software
in tickless mode.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It's possible to interrupt a thread that has already scheduled a
timeout. Really this is a race against the usage of
_add_thread_timeout() and needs some design work to provide proper
locking (which is a distinct requirement from the scheduler lock and
timeout lock!), as the users of that API are spread around the kernel.
But existing usage always schedules the timeouts first, so this is
safe.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The timeout APIs are properly synchronized now. This irq_lock() (and
the comment explaining it) isn't needed anymore.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These options are rapidly becoming a default configuration, which is
complicated by having them be hidden inside of a SYS_POWER_MANAGEMENT
variable that has to be enabled first. Put them at the top level of
the kernel config.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
