On Wed, Aug 23, 2023 at 10:26 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > 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. Yep, we'd have to introduce v2, of course. And if tomorrow we switch from maple tree to something else, we'd probably need another version of iterator as well. I made no claims that padding will be a future-proof approach, just a pragmatic mitigation of small reasonable changes in a struct we can't control. > 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. It's a tradeoff and I understand the pros and cons. Let's do mem_alloc and see how that works in practice.
