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: <ca4d9186-705c-8a69-7fce-7cff884989c0@intel.com>
Date: Wed, 5 Jul 2023 10:29:38 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Yinjun Zhang <yinjun.zhang@...igine.com>, Alexander Lobakin
	<aleksander.lobakin@...el.com>, Louis Peens <louis.peens@...igine.com>
CC: David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>, Simon Horman <simon.horman@...igine.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>, oss-drivers <oss-drivers@...igine.com>
Subject: Re: [PATCH net v2] nfp: clean mc addresses in application firmware
 when closing port



On 7/3/2023 6:50 PM, Yinjun Zhang wrote:
> On Tuesday, July 4, 2023 12:11 AM, Alexander Lobakin wrote:
>> From: Louis Peens <louis.peens@...igine.com>
>> Date: Mon,  3 Jul 2023 14:01:16 +0200
>>
>>> From: Yinjun Zhang <yinjun.zhang@...igine.com>
>>>
>>> When moving devices from one namespace to another, mc addresses are
>>> cleaned in software while not removed from application firmware. Thus
>>> the mc addresses are remained and will cause resource leak.
>>>
>>> Now use `__dev_mc_unsync` to clean mc addresses when closing port.
>>>
>>> Fixes: e20aa071cd95 ("nfp: fix schedule in atomic context when sync mc
>> address")
>>> Cc: stable@...r.kernel.org
>>> Signed-off-by: Yinjun Zhang <yinjun.zhang@...igine.com>
>>> Acked-by: Simon Horman <simon.horman@...igine.com>
>>> Signed-off-by: Louis Peens <louis.peens@...igine.com>
>>> ---
>>> Changes since v1:
>>>
>>> * Use __dev_mc_unsyc to clean mc addresses instead of tracking mc
>> addresses by
>>>   driver itself.
>>> * Clean mc addresses when closing port instead of driver exits,
>>>   so that the issue of moving devices between namespaces can be fixed.
>>> * Modify commit message accordingly.
>>>
>>>  .../ethernet/netronome/nfp/nfp_net_common.c   | 171 +++++++++---------
>>>  1 file changed, 87 insertions(+), 84 deletions(-)
>>
>> [...]
>>
>>> +static int nfp_net_mc_sync(struct net_device *netdev, const unsigned char
>> *addr)
>>> +{
>>> +	struct nfp_net *nn = netdev_priv(netdev);
>>> +
>>> +	if (netdev_mc_count(netdev) > NFP_NET_CFG_MAC_MC_MAX) {
>>> +		nn_err(nn, "Requested number of MC addresses (%d)
>> exceeds maximum (%d).\n",
>>> +		       netdev_mc_count(netdev),
>> NFP_NET_CFG_MAC_MC_MAX);
>>> +		return -EINVAL;
>>> +	}
>>> +
>>> +	return nfp_net_sched_mbox_amsg_work(nn,
>> NFP_NET_CFG_MBOX_CMD_MULTICAST_ADD, addr,
>>> +					    NFP_NET_CFG_MULTICAST_SZ,
>> nfp_net_mc_cfg);
>>> +}
>>> +
>>> +static int nfp_net_mc_unsync(struct net_device *netdev, const unsigned
>> char *addr)
>>> +{
>>> +	struct nfp_net *nn = netdev_priv(netdev);
>>> +
>>> +	return nfp_net_sched_mbox_amsg_work(nn,
>> NFP_NET_CFG_MBOX_CMD_MULTICAST_DEL, addr,
>>> +					    NFP_NET_CFG_MULTICAST_SZ,
>> nfp_net_mc_cfg);
>>> +}
>>
>> You can just declare nfp_net_mc_unsync()'s prototype here, so that it
>> will be visible to nfp_net_netdev_close(), without moving the whole set
>> of functions. Either way works, but that one would allow avoiding big
>> diffs not really related to fixing things going through the net-fixes tree.
> 
> I didn't know which was preferred. Looks like minimum change is concerned
> more. I'll change it.
> 

net-next might prefer code re-ordering and avoiding the extra
declaration, but net would definitely want the smaller fix.

For what its worth, I double check this kind of thing by applying the
patch to my git tree and using git's "color moved lines" options to diff.

Doing so for this patch shows that the change really is a straight
forward re-ordering without any additional changes accidentally included.

Thus, I have no objection to this version as-is, but a smaller v3 with
the prototype is also fine with me.

Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>

Thanks,
Jake

>>
>>> +
>>>  /**
>>>   * nfp_net_clear_config_and_disable() - Clear control BAR and disable NFP
>>>   * @nn:      NFP Net device to reconfigure
>>> @@ -1084,6 +1168,9 @@ static int nfp_net_netdev_close(struct net_device
>> *netdev)
>>>
>>>  	/* Step 2: Tell NFP
>>>  	 */
>>> +	if (nn->cap_w1 & NFP_NET_CFG_CTRL_MCAST_FILTER)
>>> +		__dev_mc_unsync(netdev, nfp_net_mc_unsync);
>>> +
>>>  	nfp_net_clear_config_and_disable(nn);
>>>  	nfp_port_configure(netdev, false);
>> [...]
>>
>> Thanks,
>> Olek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ