On Fri, Apr 05, 2019 at 10:59:27PM +0200, Daniel Borkmann wrote: > > -/* when bpf_ldimm64->src_reg == BPF_PSEUDO_MAP_FD, bpf_ldimm64->imm == fd */ > +/* When BPF ldimm64's insn[0].src_reg != 0 then this can have > + * two extensions: > + * > + * insn[0].src_reg: BPF_PSEUDO_MAP_FD BPF_PSEUDO_MAP_VALUE > + * insn[0].imm: map fd map fd > + * insn[1].imm: 0 offset into value > + * insn[0].off: 0 lower 16 bit of map index > + * insn[1].off: 0 higher 16 bit of map index > + * ldimm64 rewrite: address of map address of map[index]+offset > + * verifier type: CONST_PTR_TO_MAP PTR_TO_MAP_VALUE ... > + else if (insn->src_reg == BPF_PSEUDO_MAP_VALUE) > + snprintf(dd->scratch_buff, sizeof(dd->scratch_buff), > + "map[id:%u][%u]+%u", insn->imm, > + ((__u32)(__u16)insn[0].off) | > + ((__u32)(__u16)insn[1].off) << 16, > + (insn + 1)->imm);
Hopefully one last nit... Do we really need to allow this odd split index support? Later patches enforce array of 1 element and libbpf only uses that. This index feature feels too quirky and not really useful at this moment. Can we enforce that insn[0|1].off == 0 instead ? Later we can extend it to mean index without breaking anything.
