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 <[email protected]> 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-9512b0fb9...@toxicpanda.com?part=8
