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

Message-ID: <aIFg_yNVqTvrV6-k@mattapan.m5p.com>
Date: Wed, 23 Jul 2025 15:23:59 -0700
From: Elliott Mitchell <ehem+xen@....com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Anthoine Bourgeois <anthoine.bourgeois@...es.tech>,
        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
Subject: Re: [PATCH v2] xen/netfront: Fix TX response spurious interrupts

On Thu, Jul 17, 2025 at 07:29:51AM -0700, 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.

Sometimes the line between bugfix and optimization can be unclear.  To
me this qualifies as a bugfix since it results in non-zero values in
/sys/devices/vif-*/xenbus/spurious_events.  Spurious interrupts should
never occur, as such I would classify this as bug.

I do though think "Fixes: 0d160211965b" is more appropriate since that is
where the bug originates.  Commit b27d47950e48 merely caused the bug to
result in performance loss and trigger bug/attack detection flags.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@....com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445