From: Yonghong Song <yonghong.song@linux.dev>
To: Fabian Pfitzner <f.pfitzner@tu-braunschweig.de>, bpf@vger.kernel.org
Subject: Re: No direct copy from ctx to map possible, why?
Date: Mon, 15 Apr 2024 09:01:02 -0700 [thread overview]
Message-ID: <4f62fa70-ac50-41ff-a685-db6c8aefb017@linux.dev> (raw)
In-Reply-To: <36c8d494-e1cf-4361-8187-05abe4698791@tu-braunschweig.de>
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
>
>
>
>
next prev parent reply other threads:[~2024-04-15 16:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 21:34 No direct copy from ctx to map possible, why? Fabian Pfitzner
2024-04-15 16:01 ` Yonghong Song [this message]
2024-04-15 20:25 ` Fabian Pfitzner
2024-04-16 3:22 ` Yonghong Song
2024-04-17 19:38 ` Fabian Pfitzner
2024-04-18 0:09 ` Yonghong Song
2024-04-19 0:20 ` Andrii Nakryiko
2024-04-16 5:12 ` Hengqi Chen
2024-04-17 19:42 ` Fabian Pfitzner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f62fa70-ac50-41ff-a685-db6c8aefb017@linux.dev \
--to=yonghong.song@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=f.pfitzner@tu-braunschweig.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox