On 2/15/24 9:03 PM, Daniel Xu wrote:
Hi Yonghong,
On Wed, Feb 14, 2024 at 11:53:13AM -0800, Yonghong Song wrote:
For each active kernel thread, the thread stack size is 2*PAGE_SIZE ([1]).
Each bpf program has a maximum stack size 512 bytes to avoid
overflowing the thread stack. But nested bpf programs may post
a challenge to avoid stack overflow.
For example, currently we already allow nested bpf
programs esp in tracing, i.e.,
Prog_A
-> Call Helper_B
-> Call Func_C
-> fentry program is called due to Func_C.
-> Call Helper_D and then Func_E
-> fentry due to Func_E
-> ...
If we have too many bpf programs in the chain and each bpf program
has close to 512 byte stack size, it could overflow the kernel thread
stack.
Just curious - overflowing the thread stack would cause some kind of
panic right? And also, segmented/split stacks for bpf just reduces
Yes. immediately after normal thread stack, there is a guard page.
If there is a load/store to that guard page, kernel will panic.
likelihood of stack overflow due to BPF prog stack requirements. In
This is the intention as bpf prog will use a separate stack
for all its local variables.
theory, a deep call stack due to fentry probes could still occur, right?
Yes, although currently I did not see a lot of use cases for this, but
still it is possible.
[...]
Thanks,
Daniel
