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: <7403876c-dddf-449a-963f-10bbe43078a5@linux.microsoft.com>
Date: Mon, 10 Nov 2025 17:38:00 +0530
From: Aditya Garg <gargaditya@...ux.microsoft.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Jakub Kicinski <kuba@...nel.org>, kys@...rosoft.com,
 haiyangz@...rosoft.com, wei.liu@...nel.org, decui@...rosoft.com,
 andrew+netdev@...n.ch, davem@...emloft.net, pabeni@...hat.com,
 longli@...rosoft.com, kotaranov@...rosoft.com, horms@...nel.org,
 shradhagupta@...ux.microsoft.com, ssengar@...ux.microsoft.com,
 ernis@...ux.microsoft.com, dipayanroy@...ux.microsoft.com,
 shirazsaleem@...rosoft.com, linux-hyperv@...r.kernel.org,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-rdma@...r.kernel.org, gargaditya@...rosoft.com
Subject: Re: [PATCH net-next v2] net: mana: Handle SKB if TX SGEs exceed
 hardware limit

On 06-11-2025 18:47, Eric Dumazet wrote:
> On Thu, Nov 6, 2025 at 5:01 AM Aditya Garg
> <gargaditya@...ux.microsoft.com> wrote:
>>
>> On 06-11-2025 05:47, Jakub Kicinski wrote:
>>> On Wed, 5 Nov 2025 22:10:23 +0530 Aditya Garg wrote:
>>>>>>             if (err) {
>>>>>>                     (void)skb_dequeue_tail(&txq->pending_skbs);
>>>>>> +          mana_unmap_skb(skb, apc);
>>>>>>                     netdev_warn(ndev, "Failed to post TX OOB: %d\n", err);
>>>>>
>>>>> You have a print right here and in the callee. This condition must
>>>>> (almost) never happen in practice. It's likely fine to just drop
>>>>> the packet.
>>>>
>>>> The logs placed in callee doesn't covers all the failure scenarios,
>>>> hence I feel to have this log here with proper status. Maybe I can
>>>> remove the log in the callee?
>>>
>>> I think my point was that since there are logs (per packet!) when the
>>> condition is hit -- if it did in fact hit with any noticeable frequency
>>> your users would have complained. So handling the condition gracefully
>>> and returning BUSY is likely just unnecessary complexity in practice.
>>>
>>
>> In this, we are returning tx_busy when the error reason is -ENOSPC, for
>> all other errors, skb is dropped.
>> Is it okay requeue only for -ENOSPC cases or should we drop the skb?
> 
> I would avoid NETDEV_TX_BUSY like the plague.
> Most drivers get it wrong (including mana)
> Documentation/networking/driver.rst
> 
> Please drop the packet.
> 

Hi Eric,
Okay, Will send v3 with changes discussed.

Thanks,
Aditya

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ