Commit Graph

5 Commits

Author SHA1 Message Date
Andy Ross
419f37043b kernel/sched: Clamp minimum timeslice when TICKLESS
When the kernel is TICKLESS, timeouts are set as needed, and drivers
all have some minimum amount of time before which they can reliably
schedule an interrupt.  When this happens, drivers will kick the
requested interrupt out by one tick.  This means that it's not
reliably possible to get a timeout set for "one tick in the
future"[1].

And attempting to do that is dangerous anyway.  If the driver will
delay a one-tick interrupt, then code that repeatedly tries to
schedule an imminent interrupt may end up in a state where it is
constantly pushing the interrupt out into the future, and timer
interrupts stop arriving!  The timeout layer actually has protection
against this case.

Finally getting to the point: in recent changes, the timeslice layer
lost its integration with the "imminent" test in the timeout code, so
it's now able to run into this situation: very rapidly context
switching code (or rapidly arriving interrupts) will have the effect
of infinitely[2] delaying timeouts and stalling the whole timeout
subsystem.

Don't try to be fancy.  Just clamp timeslice duration such that a
slice is 2 ticks at minimum and we'll never hit the problem.  Adjust
the two tests that were explicitly requesting very short slice rates.

[1] Of course, the tradeoff is that the tick rate can be 100x higher
or more, so on balance tickless is a huge win.

[2] Actually it only lasts until a 31 bit signed rollover in the HPET
cycle count in practice.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2021-02-24 16:39:15 -05:00
Andrew Boie
bd8a3bba54 tests: syscalls: add torture test
Hammer all CPUs with multiple threads all making system calls
that do memory allocations and buffer validation, in the hopes
that it will help smoke out concurrency issues.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2020-02-19 12:19:43 -08:00
Ioannis Glaropoulos
31f8b6f17d tests: kernel: replace CONFIG_USERSPACE with CONFIG_TEST_USERSPACE
This commit replaces several CONFIG_USERSPACE=y
settings with CONFIG_TEST_USERSPACE=y. This allows
the test sub-system Kconfig structure to control
the settings of USERSPACE and HW_STACK_PROTECTION
in the various tests suites.

Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2019-09-03 16:44:22 +02:00
Kumar Gala
05272d62b3 tests: mem_protect: syscalls: set CONFIG_USERSPACE in prj.conf
Set CONFIG_USERSPACE in the prj.conf to ensure its set, right now
getting CONFIG_USERSPACE depends on tests/Kconfig setting it.

Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2018-09-18 17:03:57 -04:00
Andrew Boie
cef0748687 userspace: add syscalls test case
Test that we can define our own system calls in application code
and that fault handling works properly.

Additional tests for base system call infrastructure, outside of
specific system calls, go here.

Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-07-31 07:47:15 -07:00