Re-entrant syscall is tricky because we end up smashing
the return thread context and stack of the current syscall.
We stash the thread context and stack in order to make this
happen, but we have to make some assumption about the potential
stack size. There's a assert to save us if this is wrong, but
generally the kernel is extremely well behaved on stack consumption
so we shouldn't be bumping into it.
This version of the OOM handler allows us to bury the OOM
handler "anywhere", which means we can handle the hard OOM
in multiple allocation methods without having to track the entry
and exit point of every single possible one.
This means we can chop a lot of fragile code out of the kernel.
We'll do that after this commit, and some testing, to make sure
this is the right path, but it feels "much nicer".
We'll probably also cut the oom-doomer, because I think in
practice it won't be effective and it consumes a non-trivial amount
of RAM, which would otherwise make OOMs more infrequent -- probably
an amount that would be greater than the benefit that any soft-OOM
handler can get us.
The Hard OOM re-entrant syscall can actually originate in
any process space, but only from inside the kernel. Modify the
checks so that the PID==2 check is applied only to all the other
calls; and that a supervisor mode check is applied to the hard OOM
call.
This version of the OOM handler uses a syscall in a syscall
(previously forbidden) to make the OOM case deep in an alloc
situation oomable, but also have multiple exit paths.
this saves us from having to recode oodles of exit paths which
is complicated and error-prone.
I also think we should trim back some of the OOM handling paths
because it is bloating the swapper, but let's commit the current
working state before we trim stuff.
transitioning this from a mere test stub into something more fully
fledged, but encountered a problem in the kernel along the way.
so, we're committing this pile of poop so we can swap over to
a new branch and put out the kernel fire before resuming with the
refactor.
UDMA Rx busy bit seems to get stuck occassionally. This seems
to be aggravated if we insert a dcache_flush in the poll loop.
The current time-out code seems to mitigate the problem, but
I have low confidencne that this is a 100% solution. I have a feeling
we'll be revisiting this again soon.
this is a shim on top of the kernel-owned TRNG port, which uses the
SID generator function to seed a ChaCha8 CSPRNG. The CSPRNG is seeded
with 64 bits of randomness, and every 32 accesses to the CSPRNG it
gets re-seeded with 32 bits more randomness from the TRNG for better
forward secrecy.
this is currently just a stand-in to provide API compat with
with precursor keyboards. eventually we'll need to patch the console
UART (which is output to the log crate) into the keyboard as
an injector source.
for some reason a debug-print is essential for the system to run
stably. It smells like we're violating some minimum time between
accesses of SPIM interface, or else we're encoutnering some weird
optimization bug.
not quite sure why it is even there, might just be a thing from
really old code we never removed. Removing this allows us to
specify pointer types to non-copy elements, making Rust do
the hard work of figuring out how big of a block we need to zero.
in practice, we're not putting a 128M part out there, but merely
saving space for that amount of memory chews up 32k of page tracking
for something we will never use.
Tune that down to 64M, reducing the overhead to 16k. This also
matches the largest available HyperRam / FLASH part that we might
put into the XIP memory range.
some errors were made in clearing memory because we weren't
using the Rust type system to our advantage. This cleans up
the phase 1 loader to use the native types of the block plus
the slice length we intend to create to block-zero the correct
region size.
also simplify mem::size_of to size_of
- make a hard OOM more agressive about clearing memory
- add a filter on OOM Doom to de-proritize code and message
segments, meaning unused heap/stack will tend to be swapped
before code gets evicted.
This can, of course, be tuned down the road!
turns out that
- hard OOM has a clearly defined threshold: 0. we shouldn't
make it higher, because then it forces us to count free memory
on every allocation.
- it's better to have the tuning in userspace (I think) for
OOM, because that's where all the algorithms are
