On Wed, Oct 23, 2024 at 10:13 AM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote: > > On Wed, 2024-10-23 at 09:17 -0700, Eduard Zingerman wrote: > > [...] > > > > We have other places where we assume that 64 bits is enough to specify > > > stack slot index (linked regs, for instance). Do we need to update all > > > of those now as well? If yes, maybe then it's better to make sure > > > valid programs can never go beyond 512 bytes of stack even for > > > bpf_fastcall?.. > > > > Specifically function frames. > > This is a huge blunder from my side. > > The following places are problematic: > - bpf_jmp_history_entry->flags > - backtrack_state->stack_masks > > The following should be fine: > - bpf_func_state->stack > > Not sure if anything else is affected (excluding scratched_stack_slots). > > I agree that we either need to update backtracking logic, > or drop this stack extension logic. Using two u64s to describe stack slot mask is really-really inconvenient and increases memory usage by quite a lot. Given we intend to have insn_history for each instruction soon, I'd keep stack size at max of 512 bytes, even with bpf_fastcall. Is it possible?
