netdev - Re: [net-next,v25,4/6] eea: create/destroy rx,tx queues for netdevice open and stop

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: <20260204183352.00b248c4@kernel.org>
Date: Wed, 4 Feb 2026 18:33:52 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Xuan Zhuo <xuanzhuo@...ux.alibaba.com>
Cc: lorenzo@...nel.org, andrew+netdev@...n.ch, pabeni@...hat.com,
 vadim.fedorenko@...ux.dev, davem@...emloft.net, guwen@...ux.alibaba.com,
 lulie@...ux.alibaba.com, hkallweit1@...il.com, edumazet@...gle.com,
 lukas.bulwahn@...hat.com, andrew@...n.ch, dong100@...se.com,
 dust.li@...ux.alibaba.com, netdev@...r.kernel.org
Subject: Re: [net-next,v25,4/6] eea: create/destroy rx,tx queues for
 netdevice open and stop

On Thu, 5 Feb 2026 09:48:01 +0800 Xuan Zhuo wrote:
> Regarding this point, I did some experimentation and believe there are several
> issues. First, since request_irq requires passing the RX structure as callback
> data, we cannot reuse the same IRQ directlyâ€”we must first free the existing
> IRQ and then request a new one. To safely free an IRQ, the most reasonable
> approach is to stop the backend NIC's operations before releasing the IRQ. This
> constraint means we can only free the IRQ after tearing down the NIC. I've
> reviewed implementations of other NIC drivers, and they generally follow similar
> logic.
> 
> Moreover, I believe it would be quite difficult to achieve this with only minor
> modifications. In the future, we might consider introducing a proxy or an
> intermediate structure to serve as the IRQ callback data, which could enable IRQ
> reuse. However, that would likely require more substantial changes. Given that
> we've already done extensive review and refinement, I'd prefer to avoid
> introducing major refactoring at this stage.

Please TAL at commit 3a856ab34726 ("eth: fbnic: add IRQ reuse support")
for inspiration?