| 9dde212d | 25-Feb-2019 |
Etienne Carriere <etienne.carriere@linaro.org> |
core: replace TAF with TA invocation in inline comments
TAF stands for Trusted Application Function. It is deprecated
since a while. This change replaces the few remaining occurrences
with TA invoca
core: replace TAF with TA invocation in inline comments
TAF stands for Trusted Application Function. It is deprecated
since a while. This change replaces the few remaining occurrences
with TA invocation.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| bb80916b | 25-Feb-2019 |
Etienne Carriere <etienne.carriere@linaro.org> |
core: use PTA as acronym for pseudo TA
Make inline comments and trace messages more consistent by
using PTA as acronym for pseudo TA, rather than using pTA, PTA
and pta at various places.
Signed-of
core: use PTA as acronym for pseudo TA
Make inline comments and trace messages more consistent by
using PTA as acronym for pseudo TA, rather than using pTA, PTA
and pta at various places.
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| fd118772 | 12-Nov-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
core: force read-only flag on .rodata.* sections
This commit fixes a warning with GCC 8.2 that did not occur with GCC 6.2:
$ make out/arm-plat-vexpress/core/arch/arm/kernel/user_ta.o
CHK ou
core: force read-only flag on .rodata.* sections
This commit fixes a warning with GCC 8.2 that did not occur with GCC 6.2:
$ make out/arm-plat-vexpress/core/arch/arm/kernel/user_ta.o
CHK out/arm-plat-vexpress/conf.mk
CHK out/arm-plat-vexpress/include/generated/conf.h
CHK out/arm-plat-vexpress/core/include/generated/asm-defines.h
CC out/arm-plat-vexpress/core/arch/arm/kernel/user_ta.o
{standard input}: Assembler messages:
{standard input}:4087: Warning: setting incorrect section attributes for .rodata.__unpaged
The message is printed as the assembler processes this code fragment,
generated by the C compiler:
.section .rodata.__unpaged,"aw"
The older compiler (GCC 6.2) would generate instead:
.section .rodata.__unpaged,"a",%progbits
The problem with .rodata.__unpaged,"aw" is that the "w" (writeable) flag
is not consistent with the section name (.rodata.*), which by convention
is supposed to be read-only.
- The section name (".rodata.__unpaged") is given by our macro:
__rodata_unpaged.
- The "w" flag is added by GCC, not sure why exactly. One reason [1] is
when a relocatable binary is being generated and the structure contains
relocatable data. But, we are not explicitly asking for a relocatable
binary, so this might as well be a bug or counter-intuitive feature of
the compiler.
Anyway, to avoid the warning, we need to fix the section flags. The
section type (%progbits) is optional, it is deduced from the section name
by default. %progbits indicates that the section contains data (i.e., is
not empty).
Link: [1] https://gcc.gnu.org/ml/gcc/2004-05/msg01016.html
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (QEMU)
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (HiKey960)
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
show more ...
|
| ab0df69e | 15-Oct-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
core: instrument mutexes with lockdep
Implements lockdep hooks for mutexes. CFG_LOCKDEP is disabled by default,
because it causes a noticeable slowdown (plain xtest runs 2-4x slower).
Tested-by: Je
core: instrument mutexes with lockdep
Implements lockdep hooks for mutexes. CFG_LOCKDEP is disabled by default,
because it causes a noticeable slowdown (plain xtest runs 2-4x slower).
Tested-by: Jerome Forissier <jerome.forissier@linaro.org> (QEMU, HiKey960)
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|
| b3fd78c4 | 14-Sep-2018 |
Jerome Forissier <jerome.forissier@linaro.org> |
core: introduce lockdep algorithm
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a
core: introduce lockdep algorithm
This commit introduces an algorithm that may be used to detect improper
usage of locks at runtime. It can detect two kinds errors:
1. A thread tries to release a lock it does not own,
2. A thread tries to aquire a lock and the operation could *potentially*
result in a deadlock.
The potential deadlock detection assumes that the code adheres to a strict
locking hierarchy, in other word, that there is a partial ordering on the
locks so that there can be no situation where circular waits can occur. To
put things simply, any two locks should be acquired in the same order in
the same thread. This addresses the following case:
[Thread #1] [Thread #2]
lock(A)
lock(B)
lock(B)
lock(A) <-- deadlock!
...
The algorithm builds the lock hierarchy dynamically and reports as soon as
a violation is detected.
The interface is made of two functions: lockdep_lock_acquire() and
lockdep_lock_release(), which are meant to be introduced in the
implementation of the actual lock objects. The "acquire" hook tells the
algorithm that a particular lock is about to be requested by a particular
thread, while the "release" hook is meant to be called before the lock is
actually released. If an error is detected, debugging information is sent
to the console, and panic() is called. The debugging information includes
the lock cycle that was detected (in the above example, {A, B}), as well
as the call stacks at the points where the locks were acquired.
The good thing with such an instrumentation of the locking code is that
there is no need to wait for an actual deadlock to occur in order to
detect potential problems. For instance, the timing of execution in the
above example could be different but the problem would still be detected:
[Thread #1] [Thread #2]
lock(A)
lock(B)
unlock(B)
unlock(A)
lock(B)
lock(A) <-- error!
A pseudo-TA is added for testing (pta/core_lockdep_tests.c).
This code is based on two sources:
- A presentation called "Dl-Check: dynamic potential deadlock detection
tool for Java programs" [1], although the somewhat complex MNR algorithm
for topological ordering of a DAG was not used;
- A depth-first search algorithm [2] was used instead.
Link: [1] https://www.slideshare.net/IosifItkin/tmpa2017-dlcheck-dynamic-potential-deadlock-detection-tool-for-java-programs
Link: [2] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Joakim Bech <joakim.bech@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
show more ...
|