[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200820165121.GA9731@ranger.igk.intel.com>
Date: Thu, 20 Aug 2020 18:51:21 +0200
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Björn Töpel <bjorn.topel@...il.com>
Cc: Li RongQing <lirongqing@...du.com>,
Netdev <netdev@...r.kernel.org>,
intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
"Karlsson, Magnus" <magnus.karlsson@...el.com>,
Björn Töpel <bjorn.topel@...el.com>,
bpf <bpf@...r.kernel.org>, Piotr <piotr.raczynski@...el.com>,
Maciej <maciej.machnikowski@...el.com>
Subject: Re: [Intel-wired-lan] [PATCH 0/2] intel/xdp fixes for fliping rx
buffer
On Thu, Aug 20, 2020 at 05:13:16PM +0200, Björn Töpel wrote:
> On Tue, 18 Aug 2020 at 16:04, Björn Töpel <bjorn.topel@...il.com> wrote:
> >
> > On Fri, 17 Jul 2020 at 08:24, Li RongQing <lirongqing@...du.com> wrote:
> > >
> > > This fixes ice/i40e/ixgbe/ixgbevf_rx_buffer_flip in
> > > copy mode xdp that can lead to data corruption.
> > >
> > > I split two patches, since i40e/xgbe/ixgbevf supports xsk
> > > receiving from 4.18, put their fixes in a patch
> > >
> >
> > Li, sorry for the looong latency. I took a looong vacation. :-P
> >
> > Thanks for taking a look at this, but I believe this is not a bug.
> >
>
> Ok, dug a bit more into this. I had an offlist discussion with Li, and
> there are two places (AFAIK) where Li experience a BUG() in
> tcp_collapse():
>
> BUG_ON(offset < 0);
> and
> if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
> BUG();
>
> (Li, please correct me if I'm wrong.)
>
> I still claim that the page-flipping mechanism is correct, but I found
> some weirdness in the build_skb() call.
>
> In drivers/net/ethernet/intel/i40e/i40e_txrx.c, build_skb() is invoked as:
> skb = build_skb(xdp->data_hard_start, truesize);
>
> For the setup Li has truesize is 2048 (half a page), but the
> rx_buf_len is 1536. In the driver a packet is layed out as:
>
> | padding 192 | packet data 1536 | skb shared info 320 |
>
> build_skb() assumes that the second argument (frag_size) is max packet
> size + SKB_DATA_ALIGN(sizeof(struct skb_shared_info)). In other words,
> frag_size should not include the padding (192 above). In build_skb(),
Not sure I am buying that reasoning. It assumes the padding + packet_data
and we use skb_reserve() to tell the skb about the padding.
__build_skb_around() subtracts sizeof(struct skb_shared_info) from size
that we are providing, so now we are with padding + packet_data.
Then it is used to calculate the skb->end.
Back to i40e_build_skb(), we use the skb_reserve() to advance the
skb->data and skb->tail so that they point to packet_data. Finally
__skb_put() will move the skb->tail to the end of packet_data.
Wouldn't your approach disallow having the headroom at all in the linear
part of skb?
> frag_size is used to compute the skb truesize and skb end. i40e passes
IMHO skb->end is correct. For skb->truesize I would assume that the
headroom should also be taken into account for tracking how many bytes a
particular skb consumes, no?
> a too large buffer, and can therefore potentially corrupt the skb, and
> maybe this is the reason for tcp_collapse() splatting.
>
> Li, could you test if you get the splat with this patch:
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> index 3e5c566ceb01..acfb4ad9b506 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
> @@ -2065,7 +2065,8 @@ static struct sk_buff *i40e_build_skb(struct
> i40e_ring *rx_ring,
> {
> unsigned int metasize = xdp->data - xdp->data_meta;
> #if (PAGE_SIZE < 8192)
> - unsigned int truesize = i40e_rx_pg_size(rx_ring) / 2;
> + unsigned int truesize = rx_ring->rx_buf_len +
> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
This will actually break the page flipping scheme. We need a separate
variable for that and use the old truesize to bump the page_offset.
> #else
> unsigned int truesize = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
> SKB_DATA_ALIGN(xdp->data_end -
>
> I'll have a look in the other Intel drivers, and see if there are
> similar issues. I'll cook a patch.
>
>
> Björn
Powered by blists - more mailing lists