From: Edward Cree <ec...@solarflare.com> Date: Fri, 19 May 2017 21:00:13 +0100
> Well, I've managed to get somewhat confused by reg->id. > In particular, I'm unsure which bpf_reg_types can have an id, and what > exactly it means. There seems to be some code that checks around map value > pointers, which seems strange as maps have fixed sizes (and the comments in > enum bpf_reg_type make it seem like id is a PTR_TO_PACKET thing) - is this > maybe because of map-of-maps support, can the contained maps have differing > element sizes? Or do we allow *(map_value + var + imm), if map_value + var > was appropriately bounds-checked? > > Does the 'id' identify the variable that was added to an object pointer, or > the object itself? Or does it blur these and identify (what the comment in > enum bpf_reg_type calls) "skb->data + (u16) var"? The reg->id value changes any time a variable gets added to a packet pointer. You will also notice right now that only packet pointers have their alignment tracked. I have changes pending that will do that for MAP pointers too, but it needs more work.
