netdev - Re: [PATCH net] net: systemport: fix potential memory leak in bcm_sysport

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: <ed541d60-46dd-4b23-b810-548166b7a826@broadcom.com>
Date: Tue, 15 Oct 2024 11:07:29 -0700
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Wang Hai <wanghai38@...wei.com>, bcm-kernel-feedback-list@...adcom.com,
 davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
 zhangxiaoxu5@...wei.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net: systemport: fix potential memory leak in
 bcm_sysport_xmit()

On 10/15/24 11:01, Jakub Kicinski wrote:
> On Mon, 14 Oct 2024 09:59:27 -0700 Florian Fainelli wrote:
>>> diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
>>> index c9faa8540859..0a68b526e4a8 100644
>>> --- a/drivers/net/ethernet/broadcom/bcmsysport.c
>>> +++ b/drivers/net/ethernet/broadcom/bcmsysport.c
>>> @@ -1359,6 +1359,7 @@ static netdev_tx_t bcm_sysport_xmit(struct sk_buff *skb,
>>>    		netif_err(priv, tx_err, dev, "DMA map failed at %p (len=%d)\n",
>>>    			  skb->data, skb_len);
>>>    		ret = NETDEV_TX_OK;
>>> +		dev_kfree_skb_any(skb);
>>
>> Since we already have a private counter tracking DMA mapping errors, I
>> would follow what the driver does elsewhere in the transmit path,
>> especially what bcm_sysport_insert_tsb() does, and just use
>> dev_consume_skb_any() here.
> 
> Are you saying that if the packet drop is accounted is some statistics
> we should not inform drop monitor about it? 🤔️
> That wasn't my understanding of kfree_skb vs consume_skb..

Yes that's my reasoning here, now given that we have had packet drops on 
transmit that took forever to track down, maybe I better retract that 
statement and go with v1.
-- 
Florian