linux-kernel - Re: [net PATCH] net: fec: free fec queue when fec_enet_mii

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]

Date: Thu, 23 May 2024 10:23:53 +1100
From: wang xiaolei <xiaolei.wang@...driver.com>
To: Wei Fang <wei.fang@....com>, Andrew Lunn <andrew@...n.ch>
Cc: Shenwei Wang <shenwei.wang@....com>, Clark Wang <xiaoning.wang@....com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com"
 <pabeni@...hat.com>,
        "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [net PATCH] net: fec: free fec queue when fec_enet_mii_init()
 fails


On 5/22/24 6:28 PM, Wei Fang wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>> -----Original Message-----
>> From: Andrew Lunn <andrew@...n.ch>
>> Sent: 2024年5月22日 11:15
>> To: Wei Fang <wei.fang@....com>
>> Cc: Xiaolei Wang <xiaolei.wang@...driver.com>; Shenwei Wang
>> <shenwei.wang@....com>; Clark Wang <xiaoning.wang@....com>;
>> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
>> pabeni@...hat.com; imx@...ts.linux.dev; netdev@...r.kernel.org;
>> linux-kernel@...r.kernel.org
>> Subject: Re: [net PATCH] net: fec: free fec queue when fec_enet_mii_init() fails
>>
>>> The commit 59d0f7465644 ("net: fec: init multi queue date structure")
>>> was the first to introduce this issue, commit 619fee9eb13b
>>> ("net: fec: fix the potential memory leak in fec_enet_init() ") fixed
>>> this, but it does not seem to be completely fixed.
>> This fix is also not great, and i would say the initial design is really the problem.
>> There needs to be a function which is the opposite of fec_enet_init(). It can
>> then be called in the probe cleanup code, and in fec_drv_remove() which also
>> appears to leak the queues.
>>
> Yes, this issue also exists when the fec driver is unbound, maybe Xiaolei can
> help improve it in his patch.

I will add fec_enet_free_queue() to fec_drv_remove in v2 version

thanks

xiaolei