[SLOF] [PATCH slof] fdt: Avoid recursion when traversing tree
segher at kernel.crashing.org
Fri Jul 17 20:28:41 AEST 2020
On Fri, Jul 17, 2020 at 07:39:53PM +1000, Alexey Kardashevskiy wrote:
> Well, this too but it is just some waiting :)
> > you seem to be talking about dysfunction of SLOF, which would be caused
> > by stack exhaustion if I understand Segher's anwser correctly, right ?
> Right. I am a bit surprised SLOF did not barf with "stack overflow" though.
I do not know the current state of this well, so apply salt as needed...
It is much too much overhead to check the stack pointer always
(executing a single virtual machine insn is just a handful of real
machine instructions!) A traditional approach is to only check the
stack in the outer interpreter loop (where you have to find every name
that is used in the dictionary anyway, or parse numbers, or anything
else that costs thousands of cycles *anyway*!)
Many paflof configurations unmap the pages right above and below the
stacks, to trap such things. That does let slight underflows through,
because the top element is not usually actually stored on the stack.
SLOF runs in real mode, so there are no guard pages, you can write to
all RAM always.
By default the interactive interpreter prints the stack depth at every
prompt. This is very helpful while writing and testing code. And with
the "test everything you write as soon as you write it" approach, most
problems are avoided. Exceptions are capacity problems (like here), or
anything else that cannot be tested for easily (hardware problems for
So, perhaps this tree traversal code should call some "test the stack
pointers and scream" word at strategic places? At the start of handling
any subtree for example.
(If some heavier routine is called for every node, you can put the test
*there* instead, without making everything slow).
More information about the SLOF