All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Maoyi Xie <maoyixie.tju@gmail.com>
Cc: Veerasenareddy Burru <vburru@marvell.com>,
	Sathesh Edara <sedara@marvell.com>,
	Satananda Burla <sburla@marvell.com>,
	Shinas Rasheed <srasheed@marvell.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	Paolo Abeni <pabeni@redhat.com>,
	Guangshuo Li <lgs201920130244@gmail.com>,
	David Carlier <devnexen@gmail.com>,
	Simon Horman <horms@kernel.org>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net v5 0/3] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak
Date: Thu, 16 Jul 2026 15:33:56 +0200	[thread overview]
Message-ID: <aljdxFID/08xcUS+@boxer> (raw)
In-Reply-To: <20260716063432.2908100-1-maoyixie.tju@gmail.com>

On Thu, Jul 16, 2026 at 02:34:29PM +0800, Maoyi Xie wrote:
> The octeon_ep and octeon_ep_vf RX paths add one skb fragment per buffer
> with no bound against MAX_SKB_FRAGS. buff_info->len comes from the device
> response header. A long packet needs about 18 fragments. That is one past
> the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
> shinfo->frags[]. Patch 1 bounds octeon_ep. Patch 3 bounds octeon_ep_vf.
> 
> Patch 2 is Guangshuo Li's fix for an octeon_ep_vf RX page leak on the
> napi_build_skb() failure path. It touches the same drop code as patch 3.
> I carry it here so the series applies without conflict, per Maciej. Patch 3
> moves that drain loop into a helper. The helper carries the page frees from
> patch 2, so the overflow drop path frees its pages too.
> 
> octeon_ep has the same leak on its drop path. A separate patch will fix it
> once this series lands.
> 
> v5:
>  - octeon_ep, octeon_ep_vf: widen data_len to u32, per Simon Horman.
>    buff_info->len is a u64, a u16 could truncate a long length.
>  - octeon_ep: dropped Maciej Fijalkowski's Reviewed-by, the check changed.
>  - octeon_ep_vf: the drop helper drains the length in a u32 too.

The check changed however I provided certain suggestions that are included
in this set (checking frags before build_skb, wrapping common code to
helper), so I feel I still can have my review here.

For the series:
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>

> 
> v1: https://lore.kernel.org/r/20260701112825.1653044-1-maoyixie.tju@gmail.com
> v2: https://lore.kernel.org/r/20260702180518.2013324-1-maoyixie.tju@gmail.com
> v3: https://lore.kernel.org/r/20260704061511.2350737-1-maoyixie.tju@gmail.com
> v4: https://lore.kernel.org/r/20260706150208.2944898-1-maoyixie.tju@gmail.com
> 
> Guangshuo Li (1):
>   octeon_ep_vf: Fix RX page leak on napi_build_skb() failure
> 
> Maoyi Xie (2):
>   octeon_ep: fix skb frags overflow in the RX path
>   octeon_ep_vf: fix skb frags overflow in the RX path
> 
>  .../net/ethernet/marvell/octeon_ep/octep_rx.c |  9 ++++
>  .../marvell/octeon_ep_vf/octep_vf_rx.c        | 51 ++++++++++++-------
>  2 files changed, 43 insertions(+), 17 deletions(-)
> 
> --
> 2.34.1
> 

      parent reply	other threads:[~2026-07-16 13:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16  6:34 [PATCH net v5 0/3] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak Maoyi Xie
2026-07-16  6:34 ` [PATCH net v5 1/3] octeon_ep: fix skb frags overflow in the RX path Maoyi Xie
2026-07-16  6:34 ` [PATCH net v5 2/3] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure Maoyi Xie
2026-07-16  6:34 ` [PATCH net v5 3/3] octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie
2026-07-16 13:33 ` Maciej Fijalkowski [this message]

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=aljdxFID/08xcUS+@boxer \
    --to=maciej.fijalkowski@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devnexen@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=lgs201920130244@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maoyixie.tju@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sburla@marvell.com \
    --cc=sedara@marvell.com \
    --cc=srasheed@marvell.com \
    --cc=vburru@marvell.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 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.