From: Jakub Kicinski <kuba@kernel.org>
To: Aleksandr Mishin <amishin@t-argos.ru>
Cc: Veerasenareddy Burru <vburru@marvell.com>,
Sathesh Edara <sedara@marvell.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
Abhijit Ayarekar <aayarekar@marvell.com>,
Satananda Burla <sburla@marvell.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <lvc-project@linuxtesting.org>,
Simon Horman <horms@kernel.org>
Subject: Re: [PATCH net v3] octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()
Date: Fri, 4 Oct 2024 07:33:11 -0700 [thread overview]
Message-ID: <20241004073311.223efca4@kernel.org> (raw)
In-Reply-To: <20240930053328.9618-1-amishin@t-argos.ru>
On Mon, 30 Sep 2024 08:33:28 +0300 Aleksandr Mishin wrote:
> build_skb() returns NULL in case of a memory allocation failure so handle
> it inside __octep_oq_process_rx() to avoid NULL pointer dereference.
>
> __octep_oq_process_rx() is called during NAPI polling by the driver. If
> skb allocation fails, keep on pulling packets out of the Rx DMA queue: we
> shouldn't break the polling immediately and thus falsely indicate to the
> octep_napi_poll() that the Rx pressure is going down. As there is no
> associated skb in this case, don't process the packets and don't push them
> up the network stack - they are skipped.
>
> The common code with skb and some index manipulations is extracted to make
> the fix more readable and avoid code duplication. Also helper function is
> implemented to unmmap/flush all the fragment buffers used by the dropped
> packet. 'alloc_failures' counter is incremented to mark the skb allocation
> error in driver statistics.
You're doing multiple things here, please split this patch up.
--
pw-bot: cr
prev parent reply other threads:[~2024-10-04 14:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 5:33 [PATCH net v3] octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx() Aleksandr Mishin
2024-09-30 16:26 ` Simon Horman
2024-10-03 9:50 ` Paolo Abeni
2024-10-04 14:33 ` Jakub Kicinski [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=20241004073311.223efca4@kernel.org \
--to=kuba@kernel.org \
--cc=aayarekar@marvell.com \
--cc=amishin@t-argos.ru \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sburla@marvell.com \
--cc=sedara@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.