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 8/9] qlcnic: use pskb_may_pull() to pull excess TX frags into the head
Date: Thu, 08 Oct 2026 18:16:59 +0000 [thread overview]
Message-ID: <sashiko-outbox-164448@kernel.org> (raw)
In-Reply-To: <20261007-b4-pskb-pull-tail-drivers-v1-8-9512b0fb977b@toxicpanda.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] net: qlcnic: 0-length TX fragments bypass hardware descriptor limit
--
commit 8b8cbbac7b14c094feb17203e37bd51a63c158cf
Author: Josef Bacik <josef@toxicpanda.com>
qlcnic: use pskb_may_pull() to pull excess TX frags into the head
This commit replaces __pskb_pull_tail() with pskb_may_pull() in
qlcnic_xmit_frame() to pull excess TX fragments into the skb head.
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> index 761ef3bc8193a..4a81d499e51c0 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
> @@ -682,7 +682,7 @@ netdev_tx_t qlcnic_xmit_frame(struct sk_buff *skb, struct net_device *netdev)
> for (i = 0; i < (frag_count - QLCNIC_MAX_FRAGS_PER_TX); i++)
> delta += skb_frag_size(&skb_shinfo(skb)->frags[i]);
>
> - if (!__pskb_pull_tail(skb, delta))
> + if (!pskb_may_pull(skb, skb_headlen(skb) + delta))
[Severity: Medium]
Does this change bypass the hardware descriptor limit if the excess fragments
are 0-length?
When delta is 0 (due to 0-length fragments), pskb_may_pull() returns true
immediately because the requested length is already in the head. This skips
the internal call to __pskb_pull_tail().
The old code safely removed 0-length fragments by unconditionally calling
__pskb_pull_tail(skb, 0), which processes and unrefs them. Because the new
code exits early without removing these fragments, frag_count is not reduced.
Could this result in a packet exceeding the QLCNIC_MAX_FRAGS_PER_TX (14)
fragment limit being mapped and sent to the hardware, potentially causing
the NIC to hang or behave unpredictably?
> 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=8
next prev parent reply other threads:[~2026-10-08 18:17 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
2026-10-07 18:16 ` [PATCH net-next 8/9] qlcnic: " Josef Bacik
2026-10-08 18:16 ` sashiko-bot [this message]
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-164448@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