From: sashiko-bot@kernel.org
To: "Josef Bacik" <josef@toxicpanda.com>
Cc: intel-wired-lan@lists.osuosl.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH net-next 7/9] netxen: use pskb_may_pull() to pull excess TX frags into the head
Date: Thu, 08 Oct 2026 18:16:58 +0000 [thread overview]
Message-ID: <sashiko-outbox-164447@kernel.org> (raw)
In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-7-9512b0fb977b@toxicpanda.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] netxen: TX fragment hardware limit bypass due to unstripped 0-length fragments
--
commit daf1ad3622d94edcda5ee23317b335a0a1a7de23
Author: Josef Bacik <josef@toxicpanda.com>
netxen: use pskb_may_pull() to pull excess TX frags into the head
This commit replaces a direct call to __pskb_pull_tail() with pskb_may_pull()
in the netxen driver's transmit path to pull excess fragments into the head.
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> index 67d9bf69f8f29..202deb64ddefb 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> @@ -2045,7 +2045,7 @@ netxen_nic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> delta += skb_frag_size(frag);
> }
>
> - if (!__pskb_pull_tail(skb, delta))
> + if (!pskb_may_pull(skb, skb_headlen(skb) + delta))
[Severity: Medium]
Does this change bypass the hardware limit for TX fragments by failing to
strip 0-length fragments?
If an SKB is transmitted with more than 14 fragments and the first excess
fragments are 0-length, delta will be 0.
The original code handled this by calling __pskb_pull_tail() which strips
0-length fragments even when the length to eat is 0:
net/core/skbuff.c:__pskb_pull_tail() {
...
int size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
if (size <= eat) {
skb_frag_unref(skb, i);
eat -= size;
} else {
...
}
Because 0 <= 0 evaluates to true, the 0-length fragment is successfully
removed and nr_frags is reduced.
However, pskb_may_pull() returns true immediately without modifying the
SKB when requested to pull skb_headlen(skb) + 0 bytes.
This leaves the SKB with frag_count > NETXEN_MAX_FRAGS_PER_TX (14). Will
the driver then program a descriptor chain with more fragments than the
firmware supports?
> goto drop_packet;
>
> frag_count = 1 + skb_shinfo(skb)->nr_frags;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b@toxicpanda.com?part=7
next prev parent reply other threads:[~2026-10-08 18:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 18:16 [PATCH net-next 0/9] net: stop calling __pskb_pull_tail() from drivers Josef Bacik
2026-10-07 18:16 ` [PATCH net-next 1/9] net: ftmac100: check for failure when pulling in the RX header Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 2/9] net/mlx5e: check for failure when pulling the Ethernet header after XDP Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 3/9] net: niu: check for failure when pulling in the RX header Josef Bacik
2026-10-08 18:17 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 4/9] xen/netfront: check for failure when pulling in xennet_fill_frags() Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 5/9] e1000: use pskb_may_pull() in the 82544 TSO workaround Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 6/9] e1000e: use pskb_may_pull() in the 82571/2/3 " Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 7/9] netxen: use pskb_may_pull() to pull excess TX frags into the head Josef Bacik
2026-10-08 18:16 ` sashiko-bot [this message]
2026-10-07 18:16 ` [PATCH net-next 8/9] qlcnic: " Josef Bacik
2026-10-08 18:16 ` sashiko-bot
2026-10-07 18:16 ` [PATCH net-next 9/9] net: skbuff: don't reset truesize in skb_condense() if the pull fails Josef Bacik
2026-10-08 18:17 ` sashiko-bot
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=sashiko-outbox-164447@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=josef@toxicpanda.com \
--cc=linux-rdma@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox