On 17.07.25 16:29, Jakub Kicinski wrote:
On Tue, 15 Jul 2025 16:11:29 +0000 Anthoine Bourgeois wrote:Fixes: b27d47950e48 ("xen/netfront: harden netfront against event channel storms")Not entirely sure who you expect to apply this patch, but if networking then I wouldn't classify this is a fix. The "regression" happened 4 years ago. And this patch doesn't seem to be tuning the logic added by the cited commit. I think this is an optimization, -next material, and therefore there should be no Fixes tag here. You can refer to the commit without the tag.
I think in the end it is a fix of the initial xen-netfront.c contribution (commit 0d160211965b). I'm fine to change the Fixes: tag and apply the patch via the Xen tree.
@@ -849,9 +847,6 @@ static netdev_tx_t xennet_start_xmit(struct sk_buff *skb, struct net_device *dev tx_stats->packets++; u64_stats_update_end(&tx_stats->syncp);- /* Note: It is not safe to access skb after xennet_tx_buf_gc()! */- xennet_tx_buf_gc(queue); - if (!netfront_tx_slot_available(queue)) netif_tx_stop_queue(netdev_get_tx_queue(dev, queue->id));I thought normally reaping completions from the Tx path is done to prevent the queue from filling up, when the device-generated completions are slow or the queue is short. I say "normally" but this is relatively a uncommon thing to do in networking. Maybe it's my lack of Xen knowledge but it would be good to add to the commit message why these calls where here in the first place.
I guess the reason for this addition is unknown (singular, as the XDP related one was probably just a copy-and-paste), as it has been there since the first version of the driver. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
