From: netdev-bot+sashiko@kernel.org
To: josef@toxicpanda.com
Cc: kuba@kernel.org, pabeni@redhat.com, edumazet@kernel.org,
davem@davemloft.net, andrew+netdev@lunn.ch, saeedm@nvidia.com,
tariqt@nvidia.com, mbloch@nvidia.com, leon@kernel.org,
jgross@suse.com, sstabellini@kernel.org,
oleksandr_tyshchenko@epam.com, anthony.l.nguyen@intel.com,
przemyslaw.kitszel@intel.com, manishc@marvell.com,
rahulv@marvell.com, GR-Linux-NIC-Dev@marvell.com,
shshaikh@marvell.com, horms@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
xen-devel@lists.xenproject.org, intel-wired-lan@lists.osuosl.org
Subject: Re: [PATCH net-next 8/9] qlcnic: use pskb_may_pull() to pull excess TX frags into the head
Date: Sun, 11 Oct 2026 19:04:07 +0000 [thread overview]
Message-ID: <179174544742.434549.15432453849443944349@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 more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.
Low priority / nit picks for your consideration:
- [Low] In qlcnic_xmit_frame()
(drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:681-688), changing…
--
qlcnic: use pskb_may_pull() to pull excess TX frags into the head
This patch changes qlcnic_xmit_frame() so that it no longer calls
__pskb_pull_tail(skb, delta) directly when a non-GSO skb has more frags
than QLCNIC_MAX_FRAGS_PER_TX. It calls pskb_may_pull(skb,
skb_headlen(skb) + delta) instead. The commit message presents this as
an equivalent API swap.
> 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))
> goto drop_packet;
>
> frag_count = 1 + skb_shinfo(skb)->nr_frags;
[Severity: Low]
Is this exactly equivalent when delta is 0?
delta is a byte count. It is 0 if all of the leading excess frags of a
non-GSO skb with more than 14 frags are zero-length.
In that case pskb_may_pull_reason() returns early and never calls
__pskb_pull_tail():
include/linux/skbuff.h:pskb_may_pull_reason() {
...
if (likely(len <= skb_headlen(skb)))
return SKB_NOT_DROPPED_YET;
...
}
The old direct call to __pskb_pull_tail(skb, 0) always reached the
pull_pages loop. With eat == 0, every zero-size frag matches
size <= eat, so it is unreferenced and dropped from frags[]:
net/core/skbuff.c:__pskb_pull_tail() {
...
pull_pages:
eat = delta;
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
int size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
if (size <= eat) {
skb_frag_unref(skb, i);
eat -= size;
} else {
...
}
skb_shinfo(skb)->nr_frags = k;
...
}
With the new call, nr_frags does not change. The recomputed frag_count
stays above QLCNIC_MAX_FRAGS_PER_TX, and nothing checks it again.
After that, qlcnic_map_tx_skb() maps every frag, including the
zero-length ones. qlcnic_set_tx_frags_len() then writes this frag_count
into the first descriptor. The descriptor loop programs more than 14
buffers for a non-TSO packet, which the comment above this block says
the hardware does not support:
/* 14 frags supported for normal packet and
* 32 frags supported for TSO packet
*/
This needs an unusual skb layout, and no in-tree producer of it is
known. Even so, could the frag_count be rechecked after the pull, or the
commit message mention this difference?
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261007-b4-pskb-pull-tail-drivers-v1-0-9512b0fb977b%40toxicpanda.com
next prev parent reply other threads:[~2026-10-11 19:04 UTC|newest]
Thread overview: 15+ 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-07 18:16 ` [PATCH net-next 2/9] net/mlx5e: check for failure when pulling the Ethernet header after XDP Josef Bacik
2026-10-11 19:03 ` netdev-bot+sashiko
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-07 18:16 ` [PATCH net-next 4/9] xen/netfront: check for failure when pulling in xennet_fill_frags() Josef Bacik
2026-10-11 19:04 ` netdev-bot+sashiko
2026-10-07 18:16 ` [PATCH net-next 5/9] e1000: use pskb_may_pull() in the 82544 TSO workaround Josef Bacik
2026-10-07 18:16 ` [PATCH net-next 6/9] e1000e: use pskb_may_pull() in the 82571/2/3 " Josef Bacik
2026-10-11 19:04 ` netdev-bot+sashiko
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-11 19:04 ` netdev-bot+sashiko
2026-10-07 18:16 ` [PATCH net-next 8/9] qlcnic: " Josef Bacik
2026-10-11 19:04 ` netdev-bot+sashiko [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
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=179174544742.434549.15432453849443944349@kernel.org \
--to=netdev-bot+sashiko@kernel.org \
--cc=GR-Linux-NIC-Dev@marvell.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jgross@suse.com \
--cc=josef@toxicpanda.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=manishc@marvell.com \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=rahulv@marvell.com \
--cc=saeedm@nvidia.com \
--cc=shshaikh@marvell.com \
--cc=sstabellini@kernel.org \
--cc=tariqt@nvidia.com \
--cc=xen-devel@lists.xenproject.org \
/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
all inboxes | Powered by JetHome®