On Wed, Aug 23, 2023 at 10:07 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > Yes, I think we'll have to have BUILD_BUG_ON. And yes, whoever > increases vma_iter by more than 13 bytes will have to interact with > us. A bit of history. Before maple tree the vma_iterator didn't exist. vma_next would walk rb tree. So if we introduced task_vma iterator couple years ago the maple tree change would have grown our bpf_iter_task_vma by 64 bytes. If we reserved an 8 or 16 byte gap it wouldn't have helped. Hence it's wishful thinking that a gap might help in the future. Direct stack alloc of kernel data structure is also dangerous in presence of kernel debug knobs. There are no locks inside vma_iterator at the moment, but if it was there we wouldn't be able to use it on bpf prog stack regardless of its size, because lockdep on/off would have changed the size. I think it's always better to have extra indirection between bpf prog and kernel object.
