netdev - Re: [PATCH v2] xen/netfront: Fix TX response spurious interrupts

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250717072951.3bc2122c@kernel.org>
Date: Thu, 17 Jul 2025 07:29:51 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: "Anthoine Bourgeois" <anthoine.bourgeois@...es.tech>
Cc: "Juergen Gross" <jgross@...e.com>, "Stefano Stabellini"
 <sstabellini@...nel.org>, "Oleksandr Tyshchenko"
 <oleksandr_tyshchenko@...m.com>, "Wei Liu" <wei.liu@...nel.org>, "Paul
 Durrant" <paul@....org>, xen-devel@...ts.xenproject.org,
 netdev@...r.kernel.org, "Elliott Mitchell" <ehem+xen@....com>
Subject: Re: [PATCH v2] xen/netfront: Fix TX response spurious interrupts

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.

> @@ -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.
-- 
pw-bot: cr