Do not set XD at page directory level - some leaf PTE may have it
cleared.
Fixes: d1703691c8 ("x86: MMU: Generation of PAE tables")
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
This is similar fix as in commit 643cc4a22c but this one fixes
the thread parameter in UDP DTLS thread.
Fixes this function parameter datatype warning:
expected ‘k_thread_stack_t * {aka struct _k_thread_stack_element *}’
but argument is of type ‘u8_t * {aka unsigned char *}’
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
A regression by commit 9728179757 ("Allow net_context re-connect").
The code did not create IPv4 listener if IPv6 listener was successfully
created.
Fixes#4697
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
A CPU fault occurs when sys_k_event_logger_get_wait()
api invoked with config KERNEL_EVENT_LOGGER_THREAD
enabled.
sys_k_event_logger_get_wait() supposed to pend on a
semaphore when all the events from kernel event logger
are read.But when sys_k_event_logger_get_wait() inovked
with config KERNEL_EVENT_LOGGER_THREAD(i.e captures thread
events) subsquent call inside this function will write to
kernel event log buffer to capture pend event.This will
release the semaphore on which sys_k_event_logger_get_wait()
was pending hence thread gets unpend before swap gets called.
Which in other words a thread which is invoking
sys_k_event_logger_get_wait()(i. e sem_count = 0) get pends
and unpends in single function flow when KERNEL_EVENT_LOGGER_THREAD
enabled.
This would cause overlapping of the stack address where
return address of "_pend_current_thread" stored with esp of
callee saved(i. e thread->callee_saved.esp). Thus return adrress
of "_pend_current_thread" would be overwitten with zero. Which
in turn causes CPU fault.
The thread invoking sys_k_event_logger_get_wait() supposed
to only read the events of the threads which logged to kernel event
logger buffer. But it should not write to kernel event logger
buffer. Otherwise it would cause the race condition explained above.
Signed-off-by: Savinay Dharmappa <savinay.dharmappa@intel.com>
GPIO_PIN_ENABLE, GPIO_PIN_DISABLE configuration constants overlap
functionality provided by pinmux driver. They usage makes the API
inconsistent. They are almost uniformly ignored by the existing device
drivers. Only few of them take these constants into account.
This commit deprecates usage of the two configuration constants.
Signed-off-by: Piotr Mienkowski <piotr.mienkowski@gmail.com>
This patch removes checkpatch warnings as well as
make use of ztest apis to convert legacy test to ztest.
Signed-off-by: Punit Vara <punit.vara@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Now we are including fragments in whichever order glob gives is to us,
which is filesystem and any other things dependant.
Explicitly sort them, so we can reliable override things (when needed)
by specifying config file names that will be included in an well-known
specific order.
Signed-off-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>
This adds CONFIG_EXECUTE_XOR_WRITE, which is enabled by default on
systems that support controlling whether a page can contain executable
code. This is also known as W^X[1].
Trying to add a memory domain with a page that is both executable and
writable, either for supervisor mode threads, or for user mode threads,
will result in a kernel panic.
There are few cases where a writable page should also be executable
(JIT compilers, which are most likely out of scope for Zephyr), so an
option is provided to disable the check.
Since the memory domain APIs are executed in supervisor mode, a
determined person could bypass these checks with ease. This is seen
more as a way to avoid people shooting themselves in the foot.
[1] https://en.wikipedia.org/wiki/W%5EX
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Headers should only be pulling in other headers if that header
needs it somewhere in its contents. Otherwise, pulling in other
headers should be done by C files to avoid extremely difficult
dependency loops (in this case, the main kernel.h and arch/cpu.h
on ARM)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We need to start enforcing everywhere that kernel.h depends on
arch/cpu.h and any header included in the arch/cpu.h space cannot
depend on kernel.h.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We were unnecessarily pulling in headers which resulted in kernel.h
being pulled in, which is undesirable since arch/cpu.h pulls in
these headers.
Added integral type headers since we do need those.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fail on Mesh initialization if provisioning is enabled and keys were
not generated. This make it simpler to debug misconfigured devices.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
On targets where non-Zephyr controllers are likely, such as qemu, it
may be harmful to try to issue any of the vendor HCI commands, since
non-Zephyr controllers may interpret them in completely different
ways.
Introduce a Kconfig option that, when enabled, uses some simple
heuristics (HCI version & lack of public address) to try to guess in
advance whether the Zephyr HCI vendor extensions are supported or not.
The new option is available for any host-only configuration and is
enabled by default for the qemu targets.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The length and the start of the coap payload was not correct
because the received packet did not had IP and UDP header in place.
Fixes#4630
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Fixes the following conformance test regression failure
introduced in commit 7dd5fbee26 ("Bluetooth: controller:
Fix MIC error due to parallel Enc Proc")
TP/CON/MAS/BV-28-C [Initiating Connection Parameter Request
different procedure collision encryption]
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
We should call coap_update_from_block() which will determine the minimum
size of the BLOCK1 SIZE between server/client and update the current
offset and total size(if available) accordingly.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
kernel.h depends on arch.h, and reverse dependencies need to be
removed. Define k_tid_t as some opaque pointer type so that arch.h
doesn't have to pull in kernel.h.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This header needs Zephyr's specific type definitions. It also
needs struct k_mem_partition and struct k_mem_domain, but they
are defined opaquely here instead of pulling in kernel.h (which
would create nasty dependency loops)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fix to disallow initiating LE Start Encryption while another
procedure is in progress. Similarly, disallow initiating
another procedure while Encryption procedure is in progress.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
- Test ipv4/ipv6 send() and recv().
- Test ipv4/ipv6 sendto() and recvfrom().
- Test ipv4/ipv6 sendto() and recvfrom() with NULL dest address.
Signed-off-by: Aska Wu <aska.wu@linaro.org>
This adds an implementation of Xoroshiro128+ PRNG, based on the
original implementation at [1]. This pseudorandom number generator
will use the entropy driver to obtain the seed.
While it uses only 128 bits of state, it's pretty robust for non-crypto
safe applications.
[1] http://vigna.di.unimi.it/xorshift/xoroshiro128plus.c
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Instead of every hardware number generator driver providing an
implementation of this function, use the random device API to
centralize the implementation of this function.
This is a very simplistic function that can be seen as a stepping stone
to refactor the random number generation in Zephyr.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
This should clear up some of the confusion with random number
generators and drivers that obtain entropy from the hardware. Also,
many hardware number generators have limited bandwidth, so it's natural
for their output to be only used for seeding a random number generator.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Some "random" drivers are not drivers at all: they just implement the
function `sys_rand32_get()`. Move those to a random subsystem in
preparation for a reorganization.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
The CLOCK_CONTROL config option is already defined in
drivers/clock_control, so there's no need to redefine it in arch/.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Add a net_buf_id() API which translates a buffer into a zero-based
index, based on its placement in the buffer pool. This can be useful
if you want to associate an external array of meta-data contexts with
the buffers of a pool.
The added value of this API is slightly limited at the moment, since
the net_buf API allows custom user-data sizes for each pool (i.e. the
user data can be used instead of a separately allocated meta-data
array). However, there's some refactoring coming soon which will unify
all net_buf structs to have the same fixed (and typically small)
amount of user data. In such cases it may be desirable to have
external user data in order not to inflate all buffers in the system
because of a single pool needing the extra memory.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In a case we get packet without fragments return -ENODATA.
The bug was discovered by Coverity.
Fixes#4637
Coverity-CID: 178334
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
