michaelh/zephyr
1
0
Fork 0
Code Releases Activity
zephyr/tests/kernel/mem_protect/stack_random/prj.conf

10 lines
307 B
Plaintext
Raw Permalink Normal View History

tests: stack_random: Add Ztest support Add Ztest support for stack randomization test case.Ztest support for stack randomization test case. Signed-off-by: Spoorthi K <spoorthi.k@intel.com>
2018-04-05 08:39:14 +02:00
CONFIG_ZTEST=y
kernel: introduce initial stack randomization This is a component of address space layout randomization that we can implement even though we have a physical address space. Support for upward-growing stacks omitted for now, it's not done currently on any of our current or planned architectures. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-03-02 16:54:13 +01:00
CONFIG_STACK_POINTER_RANDOM=64
CONFIG_ENTROPY_GENERATOR=y
CONFIG_TEST_RANDOM_GENERATOR=y
tests: Mass SMP disablement on non-SMP-safe tests (Chunk 2 of 3 - this patch was split across pull requests to address CI build time limitations) Zephyr has always been a uniprocessor system, and its kernel tests are rife with assumptions and outright dependence on single-CPU operation (for example: "low priority threads will never run until this high priority thread blocks" -- not true if there's another processor to run it!) About 1/3 of our tests fail right now on x86_64 when dual processor operation is made default. Most of those can probably be recovered on a case-by-case basis with simple changes (and a few of them might represent real bugs in SMP!), but for now let's make sure the full test suite passes by turning the second CPU off. There's still plenty of SMP coverage in the remaining cases. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-02-22 20:45:23 +01:00
tests: Never disable SMP Disabling SMP mode for certain tests was a one-release thing, done to avoid having to triage every test independently (MANY are not SMP-safe), and with the knowledge that it was probably hiding bugs in the kernel. Turn it on pervasively. Tests are treated with a combination of flagging specific cases as "1cpu" where we have short-running tests that can be independently run in an otherwise SMP environment, and via setting CONFIG_MP_NUM_CPUS=1 where that's not possible (which still runs the full SMP kernel config, but with only one CPU available). Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-08-20 17:42:43 +02:00
# The action of the only case in this test is to spawn higher priority
# threads and assume that they have run synchronously. It can't
# possible run them on the separate CPU.
tests: move to using CONFIG_MP_MAX_NUM_CPUS For tests that set CONFIG_MP_NUM_CPUS, switch to using CONFIG_MP_MAX_NUM_CPUS instead as we work to phase out CONFIG_MP_NUM_CPUS. Signed-off-by: Kumar Gala <kumar.gala@intel.com>
2022-10-20 00:54:41 +02:00
CONFIG_MP_MAX_NUM_CPUS=1
Copy permalink