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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250912170214.GB224143@horms.kernel.org>
Date: Fri, 12 Sep 2025 18:02:14 +0100
From: Simon Horman <horms@...nel.org>
To: Sathesh B Edara <sedara@...vell.com>
Cc: linux-kernel@...r.kernel.org, sburla@...vell.com, vburru@...vell.com,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, netdev@...r.kernel.org, hgani@...vell.com,
	andrew@...n.ch, srasheed@...vell.com
Subject: Re: [net PATCH] octeon_ep:fix VF MAC address lifecycle handling

On Thu, Sep 11, 2025 at 07:49:33AM -0700, Sathesh B Edara wrote:
> Currently, VF MAC address info is not updated when the MAC address is
> configured from VF, and it is not cleared when the VF is removed. This
> leads to stale or missing MAC information in the PF, which may cause
> incorrect state tracking or inconsistencies when VFs are hot-plugged
> or reassigned.
> 
> Fix this by:
>  - storing the VF MAC address in the PF when it is set from VF
>  - clearing the stored VF MAC address when the VF is removed
> 
> This ensures that the PF always has correct VF MAC state.
> 
> Fixes: cde29af9e68e ("octeon_ep: add PF-VF mailbox communication")
> Signed-off-by: Sathesh B Edara <sedara@...vell.com>
> ---
>  drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> index ebecdd29f3bd..0867fab61b19 100644
> --- a/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_pfvf_mbox.c
> @@ -196,6 +196,7 @@ static void octep_pfvf_get_mac_addr(struct octep_device *oct,  u32 vf_id,
>  			vf_id);
>  		return;
>  	}
> +	ether_addr_copy(oct->vf_info[vf_id].mac_addr, rsp->s_set_mac.mac_addr);
>  	rsp->s_set_mac.type = OCTEP_PFVF_MBOX_TYPE_RSP_ACK;
>  }
>  
> @@ -205,6 +206,8 @@ static void octep_pfvf_dev_remove(struct octep_device *oct,  u32 vf_id,
>  {
>  	int err;
>  
> +	/* Reset VF-specific information maintained by the PF */
> +	memset(&oct->vf_info[vf_id], 0, sizeof(struct octep_pfvf_info));

Hi Sathesh,

Can the following be used here?
(completely untested)

	eth_zero_addr(oct->vf_info[vf_id].mac_addr);

Or does more of oct->vf_info[vf_id] need to be reset?

>  	err = octep_ctrl_net_dev_remove(oct, vf_id);
>  	if (err) {
>  		rsp->s.type = OCTEP_PFVF_MBOX_TYPE_RSP_NACK;
> -- 
> 2.36.0
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ