netdev - Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed hardware limit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aQjDHy5qSGYADPS7@horms.kernel.org>
Date: Mon, 3 Nov 2025 14:58:39 +0000
From: Simon Horman <horms@...nel.org>
To: Aditya Garg <gargaditya@...ux.microsoft.com>
Cc: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
	decui@...rosoft.com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	longli@...rosoft.com, kotaranov@...rosoft.com,
	shradhagupta@...ux.microsoft.com, ssengar@...ux.microsoft.com,
	ernis@...ux.microsoft.com, dipayanroy@...ux.microsoft.com,
	shirazsaleem@...rosoft.com, linux-hyperv@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-rdma@...r.kernel.org, gargaditya@...rosoft.com
Subject: Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed
 hardware limit

On Fri, Oct 31, 2025 at 06:50:10PM +0530, Aditya Garg wrote:
> On 30-10-2025 14:34, Simon Horman wrote:
> > On Wed, Oct 29, 2025 at 06:12:35AM -0700, Aditya Garg wrote:
> > > The MANA hardware supports a maximum of 30 scatter-gather entries (SGEs)
> > > per TX WQE. Exceeding this limit can cause TX failures.
> > > Add ndo_features_check() callback to validate SKB layout before
> > > transmission. For GSO SKBs that would exceed the hardware SGE limit, clear
> > > NETIF_F_GSO_MASK to enforce software segmentation in the stack.
> > > Add a fallback in mana_start_xmit() to linearize non-GSO SKBs that still
> > > exceed the SGE limit.
> > > 
> > > Return NETDEV_TX_BUSY only for -ENOSPC from mana_gd_post_work_request(),
> > > send other errors to free_sgl_ptr to free resources and record the tx
> > > drop.
> > > 
> > > Co-developed-by: Dipayaan Roy <dipayanroy@...ux.microsoft.com>
> > > Signed-off-by: Dipayaan Roy <dipayanroy@...ux.microsoft.com>
> > > Signed-off-by: Aditya Garg <gargaditya@...ux.microsoft.com>
> > 
> > ...
> > 
> > > @@ -289,6 +290,21 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> > >   	cq = &apc->tx_qp[txq_idx].tx_cq;
> > >   	tx_stats = &txq->stats;
> > > +	if (MAX_SKB_FRAGS + 2 > MAX_TX_WQE_SGL_ENTRIES &&
> > > +	    skb_shinfo(skb)->nr_frags + 2 > MAX_TX_WQE_SGL_ENTRIES) {
> > > +		/* GSO skb with Hardware SGE limit exceeded is not expected here
> > > +		 * as they are handled in mana_features_check() callback
> > > +		 */
> > 
> > Hi,
> > 
> > I'm curious to know if we actually need this code.
> > Are there cases where the mana_features_check() doesn't
> > handle things and the kernel will reach this line?
> > 
> > > +		if (skb_is_gso(skb))
> > > +			netdev_warn_once(ndev, "GSO enabled skb exceeds max SGE limit\n");
> > > +		if (skb_linearize(skb)) {
> > > +			netdev_warn_once(ndev, "Failed to linearize skb with nr_frags=%d and is_gso=%d\n",
> > > +					 skb_shinfo(skb)->nr_frags,
> > > +					 skb_is_gso(skb));
> > > +			goto tx_drop_count;
> > > +		}
> > > +	}
> > > +
> > >   	pkg.tx_oob.s_oob.vcq_num = cq->gdma_id;
> > >   	pkg.tx_oob.s_oob.vsq_frame = txq->vsq_frame;
> > 
> > ...
> 
> Hi Simon,
> As it was previously discussed and agreed on with Eric, this is for Non-GSO
> skbs which could have possibly nr_frags greater than hardware limit.
> 
> Quoting Eric's comment from v1 thread: https://lore.kernel.org/netdev/CANn89iKwHWdUaeAsdSuZUXG-W8XwyM2oppQL9spKkex0p9-Azw@mail.gmail.com/
> "I think that for non GSO, the linearization attempt is fine.
> 
> Note that this is extremely unlikely for non malicious users,
> and MTU being usually small (9K or less),
> the allocation will be much smaller than a GSO packet."

Thanks for the clarification, that makes sense to me.

FTR, Jakub's question (elsewhere) is different to mine.