netdev - Re: [PATCH net-next] ibmveth: Always stop tx queues during close

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]

Date:   Tue, 18 Oct 2022 16:00:14 -0500
From:   Nick Child <nnac123@...ux.ibm.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, nick.child@....com
Subject: Re: [PATCH net-next] ibmveth: Always stop tx queues during close

Hello Jakub,

Thanks for the review,

On 10/18/22 13:47, Jakub Kicinski wrote:
> On Mon, 17 Oct 2022 10:17:43 -0500 Nick Child wrote:
>> The issue with this approach was that the hypervisor freed all of
>> the devices control structures after the hcall H_FREE_LOGICAL_LAN
>> was performed but the transmit queues were never stopped. So the higher
>> layers in the network stack would continue transmission but any
>> H_SEND_LOGICAL_LAN hcall would fail with H_PARAMETER until the
>> hypervisor's structures for the device were allocated with the
>> H_REGISTER_LOGICAL_LAN hcall in ibmveth_open.
> 
> Sounds like we should treat this one as a fix as well?

Agreed. I will resend with `net` tag.

> How far back is it safe to backport?
The issue is introduced in commit 860f242eb534 ("[PATCH] ibmveth change 
buffer pools dynamically") which first appears in v3.19.
Please let me know if I should resend with "Fixes:".

Since the aforementioned commit, multiple other patches have mimicked 
the behavior. Because the same bad logic is used in multiple places, 
their will be multiple merge conflicts depending on the LTS branch. From
what I can tell the patch will differ between the one posted here 
(v6.1), LTS v4.14-5.15, and LTS v4.9.

Since the issue only results in annoying "failed to send" driver 
messages and is under no pressure to get backported from end users, we 
are okay if it does not get backported. That being said, if you would 
like to see it backported, I can send you the patches that would apply
cleanly to v4.9 and v4.14-v5.15.

If there is anything else I can do please let me know.

Thanks again,
Nick Child