All of lore.kernel.org
 help / color / mirror / Atom feed
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
>
>
>
>

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.