* Re: [PATCH net] nfp: clean mc addresses in application firmware when driver exits [not found] <20230628093228.12388-1-louis.peens@corigine.com> @ 2023-06-28 20:59 ` Jakub Kicinski 2023-06-30 4:49 ` Yinjun Zhang [not found] ` <4cc91766-998a-697c-8adb-fcc864f1be62@intel.com> 1 sibling, 1 reply; 3+ messages in thread From: Jakub Kicinski @ 2023-06-28 20:59 UTC (permalink / raw) To: Louis Peens Cc: David Miller, Paolo Abeni, Simon Horman, Yinjun Zhang, netdev, stable, oss-drivers On Wed, 28 Jun 2023 11:32:28 +0200 Louis Peens wrote: > The configured mc addresses are not removed from application firmware > when driver exits. This will cause resource leak when repeatedly > creating and destroying VFs. I think the justification is somewhat questionable, too. VF is by definition not trusted. Does FLR not clean up the resources? ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: [PATCH net] nfp: clean mc addresses in application firmware when driver exits 2023-06-28 20:59 ` [PATCH net] nfp: clean mc addresses in application firmware when driver exits Jakub Kicinski @ 2023-06-30 4:49 ` Yinjun Zhang 0 siblings, 0 replies; 3+ messages in thread From: Yinjun Zhang @ 2023-06-30 4:49 UTC (permalink / raw) To: Jakub Kicinski, Louis Peens Cc: David Miller, Paolo Abeni, Simon Horman, netdev@vger.kernel.org, stable@vger.kernel.org, oss-drivers On Thursday, June 29, 2023 4:59 AM, Jakub Kicinski wrote: > On Wed, 28 Jun 2023 11:32:28 +0200 Louis Peens wrote: > > The configured mc addresses are not removed from application firmware > > when driver exits. This will cause resource leak when repeatedly > > creating and destroying VFs. > > I think the justification is somewhat questionable, too. > VF is by definition not trusted. Does FLR not clean up the resources? Sorry, it doesn't. And I also find that moving netdev from one namespace to another causes the same problem. So this fix is not for the VF case only. ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <4cc91766-998a-697c-8adb-fcc864f1be62@intel.com>]
* RE: [PATCH net] nfp: clean mc addresses in application firmware when driver exits [not found] ` <4cc91766-998a-697c-8adb-fcc864f1be62@intel.com> @ 2023-06-30 4:43 ` Yinjun Zhang 0 siblings, 0 replies; 3+ messages in thread From: Yinjun Zhang @ 2023-06-30 4:43 UTC (permalink / raw) To: Jacob Keller, Louis Peens, David Miller, Jakub Kicinski, Paolo Abeni Cc: Simon Horman, netdev@vger.kernel.org, stable@vger.kernel.org, oss-drivers On Thursday, June 29, 2023 2:21 AM, Jacob Keller wrote: > > Is there no way to just ask the kernel what addresses you already have > and avoid the need for a separate copy maintained in the driver? Or > maybe thats something that could be added since this doesn't seem like a > unique problem. > > In fact, we absolutely can: > > __dev_mc_unsync which is the opposite of __dev_mc_sync. > > You can just call that during tear down with an unsync function and you > shouldn't need to bother maintaining your own list at all. Yes, you're right, I'll use _unsync. Thank you. > > > nfp_net_reconfig_wait_posted(nn); > > } ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-06-30 4:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230628093228.12388-1-louis.peens@corigine.com>
2023-06-28 20:59 ` [PATCH net] nfp: clean mc addresses in application firmware when driver exits Jakub Kicinski
2023-06-30 4:49 ` Yinjun Zhang
[not found] ` <4cc91766-998a-697c-8adb-fcc864f1be62@intel.com>
2023-06-30 4:43 ` Yinjun Zhang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).