fix: init reg[2] as mbuff.len()

[hsqStephenZhang]

No description provided.

[qmonnet]

Thanks! But I'm not sure I want that, this looks like a difference in behaviour with what the kernel does.

If you need to know the length of your mem area, you should specify it in the relevant field of the mbuff. The mbuff would typically have a constant size, and (as long as we don't have a better verifier) it would be up to the user to make sure that the program doesn't attempt to reach beyond the mbuff size. This is to mimic what we have in the kernel with packets and metadata buffers. Meanwhile, reg[2] typically starts with a 0 value, if I'm not mistaken.

[hsqStephenZhang]

Thanks for your detailed explanation. sorry i did not mention the context, here is how ubpf handled reg[2], which I thought might be a better reference for userspace implementation.

But i'm ok with your considerations.

[qmonnet]

Thanks for the context. I see that iovisor/ubpf#57 says “The eBPF spec allows R1-R5 to be used for such purposes”. I believe it refers to this draft:

Upon entering execution of an eBPF program, registers R1 - R5 initially can contain the input arguments for the program (similar to the argc/argv pair for a typical C program). The actual number of registers used, and their meaning, is defined by the program type; for example, a networking program might have an argument that includes network packet data and/or metadata.

But this convention never explicitly made it to the final ISA specification. So there's no real convention as far as I know.

This change probably makes more sense for uBPF, which doesn't work with mbuffs as far as I remember. I think I'll stick to the kernel behaviour in rbpf for now, unless there's a strong demand for use cases that mbuff cannot addressed.

[hsqStephenZhang]

Got it. Thanks!