eBPF (extended Berkeley Packet Filter) is a linux subsystem that enables you to probe around the kernel, make schedulers (SCHED_EXT) and more. All of that using a JIT(Just in time) compiler. more here:What is eBPF? An Introduction and Deep Dive into the eBPF Technology

Kfuncs are the way BPF will interact with different part of the kernel, having these available means that a job that would require a kernel module before can now be done with a BPF program.

Max stack size is 512bytes located using a pointer in the r10 register(X86).^[1]

There is a new kmem_cache iterator that enables BPF programs to obtain information about the state of the slab allocator.^[3]

-The new bpf_send_signal_task() kfunc allows a BPF program to send a signal to another process. There is nothing info wise but lwn with that patch... ^[3]

Sometime some BPF scheduler (SCHED_EXT) can require some extra info from the process running under them. This patchset enables every task in every process to share a small chunk of memory of it's own with a BPF scheduler. So, they can update the hints without expensive overhead of syscalls. It also wants every task sees only the data/memory belong to the task/or the task's process.^[2]

There has been an issues with BPF causing a stack overflow, here is a couple of slide talking about it: LPC2023_slides

TLDR: BPF stack size is 512B and it fits inside of a kernel stack which is 16KB. The BPF under some circumstances can grow above 512B by calling another BPF program in a specific way. Now even if there is a limit to how many time you can call another BPF in that way, we need to keep in mind that the kernel stack may already contain a bunch of thing so growing too much above our 512B is really bad.

One example something that could be a problem would be the SCHED_EXT on the machine.

The solution is to detect when BPF is going to take more stack memory (64B over the 512B to be precise) and give the new BPF program its own new stack, mitigating the issue.^[4]