Re: [LSF/MM/BPF TOPIC] Segmented Stacks for BPF Programs

[Yonghong Song <yonghong.song@linux.dev>]

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