Looks like you intend to copy packet data. So from the above,
'expected=fp,pkt,pkt_meta...', you can just put the first argument
with xdp->data, right?
Yes, I intend to copy packet data. What do you mean by "first argument"?
I'd like to put the whole data that is depicted by xdp->data into a map
that stores them as raw bytes (by using a char array as map element to
store the data).
Verifer rejects to 'ctx' since 'ctx' contents are subject to verifier
rewrite. So actual 'ctx' contents/layouts may not match uapi definition.
Sorry but I do not understand what you mean by "subject to verifier
rewrite". What kind of rewrite happens when using the ctx as argument?
Furthermore, am I correct that you assume that the uapi may dictate the
structure of the data that can be stored in a map? How is it different
to the case when first storing it on the stack and then putting it into
a map?
On 4/15/24 6:01 PM, Yonghong Song wrote:
On 4/14/24 2:34 PM, Fabian Pfitzner wrote:
Hello,
is there a specific reason why it is not allowed to copy data from
ctx directly into a map via the bpf_map_update_elem helper?
I develop a XDP program where I need to store incoming packets
(including the whole payload) into a map in order to buffer them.
I thought I could simply put them into a map via the mentioned helper
function, but the verifier complains about expecting another type as
"ctx" (R3 type=ctx expected=fp, pkt, pkt_meta, .....).
Looks like you intend to copy packet data. So from the above,
'expected=fp,pkt,pkt_meta...', you can just put the first argument
with xdp->data, right?
Verifer rejects to 'ctx' since 'ctx' contents are subject to verifier
rewrite. So actual 'ctx' contents/layouts may not match uapi definition.
I was able to circumvent this error by first putting the packet onto
the stack (via xdp->data) and then write it into the map.
The only limitation with this is that I cannot store packets larger
than 512 bytes due to the maximum stack size.
I was also able to circumvent this by slicing chunks, that are
smaller than 512 bytes, out of the packet so that I can use the stack
as a clipboard before putting them into the map. This is a really
ugly solution, but I have not found a better one yet.
So my question is: Why does this limitation exist? I am not sure if
its only related to XDP programs as this restriction is defined
inside of the bpf_map_update_elem_proto struct (arg3_type restricts
this), so I think it is a general limitation that affects all program
types.
Best regards,
Fabian Pfitzner
