From: Simon Horman <horms@kernel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, netdev@vger.kernel.org,
magnus.karlsson@intel.com, bjorn@kernel.org, echaudro@redhat.com,
lorenzo@kernel.org, martin.lau@linux.dev,
tirthendu.sarkar@intel.com, john.fastabend@gmail.com
Subject: Re: [PATCH v4 bpf 05/11] i40e: handle multi-buffer packets that are shrunk by xdp prog
Date: Sat, 20 Jan 2024 11:35:41 +0000 [thread overview]
Message-ID: <20240120113541.GA110624@kernel.org> (raw)
In-Reply-To: <20240119233037.537084-6-maciej.fijalkowski@intel.com>
On Sat, Jan 20, 2024 at 12:30:31AM +0100, Maciej Fijalkowski wrote:
> From: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
>
> XDP programs can shrink packets by calling the bpf_xdp_adjust_tail()
> helper function. For multi-buffer packets this may lead to reduction of
> frag count stored in skb_shared_info area of the xdp_buff struct. This
> results in issues with the current handling of XDP_PASS and XDP_DROP
> cases.
>
> For XDP_PASS, currently skb is being built using frag count of
> xdp_buffer before it was processed by XDP prog and thus will result in
> an inconsistent skb when frag count gets reduced by XDP prog. To fix
> this, get correct frag count while building the skb instead of using
> pre-obtained frag count.
>
> For XDP_DROP, current page recycling logic will not reuse the page but
> instead will adjust the pagecnt_bias so that the page can be freed. This
> again results in inconsistent behavior as the page count has already
> been changed by the helper while freeing the frag(s) as part of
> shrinking the packet. To fix this, only adjust pagecnt_bias for buffers
> that are stillpart of the packet post-xdp prog run.
>
> Fixes: e213ced19bef ("i40e: add support for XDP multi-buffer Rx")
> Reported-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Tested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
...
> @@ -2129,20 +2130,20 @@ static void i40e_process_rx_buffs(struct i40e_ring *rx_ring, int xdp_res,
> * i40e_construct_skb - Allocate skb and populate it
> * @rx_ring: rx descriptor ring to transact packets on
> * @xdp: xdp_buff pointing to the data
> - * @nr_frags: number of buffers for the packet
> *
> * This function allocates an skb. It then populates it with the page
> * data from the current receive descriptor, taking care to set up the
> * skb correctly.
> */
> static struct sk_buff *i40e_construct_skb(struct i40e_ring *rx_ring,
> - struct xdp_buff *xdp,
> - u32 nr_frags)
> + struct xdp_buff *xdp)
> {
> unsigned int size = xdp->data_end - xdp->data;
> struct i40e_rx_buffer *rx_buffer;
> + struct skb_shared_info *sinfo;
> unsigned int headlen;
> struct sk_buff *skb;
> + u32 nr_frags;
>
> /* prefetch first cache line of first page */
> net_prefetch(xdp->data);
> @@ -2180,6 +2181,10 @@ static struct sk_buff *i40e_construct_skb(struct i40e_ring *rx_ring,
> memcpy(__skb_put(skb, headlen), xdp->data,
> ALIGN(headlen, sizeof(long)));
>
> + if (unlikely(xdp_buff_has_frags(xdp))) {
> + sinfo = xdp_get_shared_info_from_buff(xdp);
> + nr_frags = sinfo->nr_frags;
> + }
> rx_buffer = i40e_rx_bi(rx_ring, rx_ring->next_to_clean);
> /* update all of the pointers */
> size -= headlen;
Hi Maciej,
Above, nr_frags is initialised only if xdp_buff_has_frags(xdp) is true.
The code immediately following this hunk is:
if (size) {
if (unlikely(nr_frags >= MAX_SKB_FRAGS)) {
...
Can it be the case that nr_frags is used uninitialised here?
Flagged by Smatch.
...
next prev parent reply other threads:[~2024-01-20 11:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-19 23:30 [PATCH v4 bpf 00/11] net: bpf_xdp_adjust_tail() and Intel mbuf fixes Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 01/11] xsk: recycle buffer in case Rx queue was full Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 02/11] xsk: make xsk_buff_pool responsible for clearing xdp_buff::flags Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 03/11] xsk: fix usage of multi-buffer BPF helpers for ZC XDP Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 04/11] ice: work on pre-XDP prog frag count Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 05/11] i40e: handle multi-buffer packets that are shrunk by xdp prog Maciej Fijalkowski
2024-01-20 11:35 ` Simon Horman [this message]
2024-01-22 14:08 ` Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 06/11] ice: remove redundant xdp_rxq_info registration Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 07/11] intel: xsk: initialize skb_frag_t::bv_offset in ZC drivers Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 08/11] ice: update xdp_rxq_info::frag_size for ZC enabled Rx queue Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 09/11] xdp: reflect tail increase for MEM_TYPE_XSK_BUFF_POOL Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 10/11] i40e: set xdp_rxq_info::frag_size Maciej Fijalkowski
2024-01-19 23:30 ` [PATCH v4 bpf 11/11] i40e: update xdp_rxq_info::frag_size for ZC enabled Rx queue Maciej Fijalkowski
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=20240120113541.GA110624@kernel.org \
--to=horms@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=echaudro@redhat.com \
--cc=john.fastabend@gmail.com \
--cc=lorenzo@kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=tirthendu.sarkar@intel.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