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>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net v4 2/3] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure
Date: Mon, 6 Jul 2026 18:10:28 +0200 [thread overview]
Message-ID: <akvTdFCJ2a/bCM+1@boxer> (raw)
In-Reply-To: <20260706150208.2944898-3-maoyixie.tju@gmail.com>
On Mon, Jul 06, 2026 at 11:02:07PM +0800, Maoyi Xie wrote:
> From: Guangshuo Li <lgs201920130244@gmail.com>
>
> __octep_vf_oq_process_rx() clears buff_info->page before building an skb
> from the RX page. On the success path the page is consumed by the skb,
> either as the skb head or as an RX fragment.
>
> If napi_build_skb() fails, however, the page is not consumed by an skb.
> The error path advances the descriptor and leaves the ring slot cleared,
> so the page is no longer tracked and is leaked. In the multi-fragment
> case, the remaining fragment pages are also unmapped and removed from
> their ring slots without being released.
>
> Release the head page when napi_build_skb() fails, and release each
> remaining fragment page before clearing its ring slot.
>
> Fixes: dd66b4285470 ("octeon_ep_vf: add NULL check for napi_build_skb()")
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> index d982474082..302559b16b 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
> @@ -418,6 +418,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
> skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> oq->stats->alloc_failures++;
> + put_page(virt_to_page(resp_hw));
> desc_used++;
> read_idx = octep_vf_oq_next_idx(oq, read_idx);
> continue;
> @@ -434,6 +435,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
> skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
> if (!skb) {
> oq->stats->alloc_failures++;
> + put_page(virt_to_page(resp_hw));
> desc_used++;
> read_idx = octep_vf_oq_next_idx(oq, read_idx);
> data_len = buff_info->len - oq->max_single_buffer_size;
> @@ -442,6 +444,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
> PAGE_SIZE, DMA_FROM_DEVICE);
> buff_info = (struct octep_vf_rx_buffer *)
> &oq->buff_info[read_idx];
> + put_page(buff_info->page);
> buff_info->page = NULL;
> if (data_len < oq->buffer_size)
> data_len = 0;
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-07-06 16:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 15:02 [PATCH net v4 0/3] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak Maoyi Xie
2026-07-06 15:02 ` [PATCH net v4 1/3] octeon_ep: fix skb frags overflow in the RX path Maoyi Xie
2026-07-13 11:06 ` Simon Horman
2026-07-06 15:02 ` [PATCH net v4 2/3] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure Maoyi Xie
2026-07-06 16:10 ` Maciej Fijalkowski [this message]
2026-07-06 15:02 ` [PATCH net v4 3/3] octeon_ep_vf: fix skb frags overflow in the RX path 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=akvTdFCJ2a/bCM+1@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=devnexen@gmail.com \
--cc=edumazet@google.com \
--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.