public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Song Liu" <song@kernel.org>,
	"Jesper Dangaard Brouer" <hawk@kernel.org>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Martin KaFai Lau" <martin.lau@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>
Subject: Re: [PATCH bpf-next v5] bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES
Date: Tue, 21 Feb 2023 09:52:52 -0800	[thread overview]
Message-ID: <d6388f1d-13d3-d844-eca2-a4874e5c70cb@linux.dev> (raw)
In-Reply-To: <36538615-7768-bdea-7829-6349729ab7cc@intel.com>

On 2/21/23 4:35 AM, Alexander Lobakin wrote:
> From: Alexander Lobakin <aleksander.lobakin@intel.com>
> Date: Mon, 20 Feb 2023 16:46:27 +0100
> 
>> &xdp_buff and &xdp_frame are bound in a way that
>>
>> xdp_buff->data_hard_start == xdp_frame
>>
>> It's always the case and e.g. xdp_convert_buff_to_frame() relies on
>> this.
>> IOW, the following:
>>
>> 	for (u32 i = 0; i < 0xdead; i++) {
>> 		xdpf = xdp_convert_buff_to_frame(&xdp);
>> 		xdp_convert_frame_to_buff(xdpf, &xdp);
>> 	}
>>
>> shouldn't ever modify @xdpf's contents or the pointer itself.
>> However, "live packet" code wrongly treats &xdp_frame as part of its
>> context placed *before* the data_hard_start. With such flow,
>> data_hard_start is sizeof(*xdpf) off to the right and no longer points
>> to the XDP frame.
>>
>> Instead of replacing `sizeof(ctx)` with `offsetof(ctx, xdpf)` in several
>> places and praying that there are no more miscalcs left somewhere in the
>> code, unionize ::frm with ::data in a flex array, so that both starts
>> pointing to the actual data_hard_start and the XDP frame actually starts
>> being a part of it, i.e. a part of the headroom, not the context.
>> A nice side effect is that the maximum frame size for this mode gets
>> increased by 40 bytes, as xdp_buff::frame_sz includes everything from
>> data_hard_start (-> includes xdpf already) to the end of XDP/skb shared
>> info.
>> Also update %MAX_PKT_SIZE accordingly in the selftests code. Leave it
>> hardcoded for 64 bit && 4k pages, it can be made more flexible later on.
>>
>> Minor: align `&head->data` with how `head->frm` is assigned for
>> consistency.
>> Minor #2: rename 'frm' to 'frame' in &xdp_page_head while at it for
>> clarity.
>>
>> (was found while testing XDP traffic generator on ice, which calls
>>   xdp_convert_frame_to_buff() for each XDP frame)
> 
> Sorry, maybe this could be taken directly to net-next while it's still
> open? It was tested and then reverted from bpf-next only due to not 100%
> compile-time assertion, which I removed in this version. No more
> changes. I doubt there'll be a second PR from bpf and would like this to
> hit mainline before RC1 :s

I think this could go to bpf soon instead of bpf-next. The change is specific to 
the bpf selftest. It is better to go through bpf to get bpf CI coverage.

> 
>>
>> Fixes: b530e9e1063e ("bpf: Add "live packet" mode for XDP in BPF_PROG_RUN")
>> Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
>> Link: https://lore.kernel.org/r/20230215185440.4126672-1-aleksander.lobakin@intel.com
>> Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
> (>_< those two last tags are incorrect, lemme know if I should resubmit
>   it without them or you could do it if ok with taking it now)

Please respin when it can be landed to the bpf tree on top of the s390 changes.

  reply	other threads:[~2023-02-21 17:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-20 15:46 [PATCH bpf-next v5] bpf, test_run: fix &xdp_frame misplacement for LIVE_FRAMES Alexander Lobakin
2023-02-21 12:35 ` Alexander Lobakin
2023-02-21 17:52   ` Martin KaFai Lau [this message]
2023-02-21 17:55     ` Alexander Lobakin

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=d6388f1d-13d3-d844-eca2-a4874e5c70cb@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hawk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=song@kernel.org \
    --cc=toke@redhat.com \
    /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