All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
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>,
	Paolo Abeni <pabeni@redhat.com>,
	Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	Simon Horman <horms@kernel.org>,
	Guangshuo Li <lgs201920130244@gmail.com>,
	David Carlier <devnexen@gmail.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak
Date: Wed, 22 Jul 2026 09:04:43 -0700	[thread overview]
Message-ID: <20260722090443.0c24a5df@kernel.org> (raw)
In-Reply-To: <20260722155131.2017597-1-maoyixie.tju@gmail.com>

On Wed, 22 Jul 2026 23:51:27 +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. skb_add_rx_frag() then writes past
> shinfo->frags[]. Patch 2 bounds octeon_ep. Patch 4 bounds octeon_ep_vf.
> 
> Both drivers also leak the pages of a dropped multi-buffer packet. The
> drop path unmaps each buffer but never frees its page. Patch 1 fixes
> octeon_ep. Patch 3 is Guangshuo Li's fix for octeon_ep_vf. The overflow
> drops in patch 2 and patch 4 reuse those helpers. They free their pages
> too.
> 
> The drop drain length derives from the device length. It had no bound
> against the ring. Patch 1 and patch 4 stop the drain after MAX_SKB_FRAGS
> fragments. A valid packet never holds more. This keeps a bad device length
> from running the drain past the ring.

I'm asking you for the second time - why are you working on this driver?
Do you have HW to test this?
This driver is orphaned, it's been nothing but bugs for years, if nobody
has this HW we should just delete this crap.

  parent reply	other threads:[~2026-07-22 16:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22 15:51 [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak Maoyi Xie
2026-07-22 15:51 ` [PATCH net v6 1/4] octeon_ep: free the dropped RX buffer pages Maoyi Xie
2026-07-22 15:51 ` [PATCH net v6 2/4] octeon_ep: fix skb frags overflow in the RX path Maoyi Xie
2026-07-22 15:51 ` [PATCH net v6 3/4] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure Maoyi Xie
2026-07-22 15:51 ` [PATCH net v6 4/4] octeon_ep_vf: fix skb frags overflow in the RX path Maoyi Xie
2026-07-22 16:04 ` Jakub Kicinski [this message]
2026-07-22 16:47   ` [PATCH net v6 0/4] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak Maoyi Xie

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=20260722090443.0c24a5df@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devnexen@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=lgs201920130244@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --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.