On 7/23/24 8:17 PM, Alexei Starovoitov wrote:
On Mon, Jul 22, 2024 at 8:27 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
We *need to support recursion* is my main point.
Not quite.
It's not a recursion. The stack collapsed/gone/wiped out before tail_call.
Only of subprog(), not of handle_tp(). See all those "ENTRY - AFTER"
messages. We do return to all the nested handle_tp() calls and
continue just fine.
I put the log into [0] for a bit easier visual inspection.
[0] https://gist.github.com/anakryiko/6ccdfc62188f8ad4991641fb637d954c
Argh. So the pathological prog can consume 512*33 of stack.
We have a check in verifier like below:
if (idx && subprog[idx].has_tail_call && depth >= 256) {
verbose(env,
"tail_calls are not allowed when call stack of previous frames is %d bytes. Too large\n",
depth);
return -EACCES;
}
So the maximum stack size could be around 256 * 33 which is a little bit more than 8KB.
We have to reject it somehow in the verifier or tailor private stack
to support it. Then private stack will be a feature and a fix for this issue.
But then it would need to preallocate 512*33 per cpu per program.
Which is too much.
Maybe we can preallocate _aligned_ 512 or 1k per cpu per prog,
then adjust r9 before call or tail_call and if r9 is about to cross
alignment before tail_call fail the tail call (like tail call cnt was
over limit).
Hopefully there are better ideas, since it's all quite messy.
