netdev - Re: [PATCH intel-next v1] ice: be consistent around PTP de-registration

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: <afcafd64-d7d8-41cd-8979-c76aaf4c1b04@intel.com>
Date: Wed, 9 Apr 2025 14:54:48 -0700
From: Tony Nguyen <anthony.l.nguyen@...el.com>
To: Jesse Brandeburg <jbrandeb@...nel.org>, <intel-wired-lan@...ts.osuosl.org>
CC: <netdev@...r.kernel.org>, Przemek Kitszel <przemyslaw.kitszel@...el.com>,
	Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, "Paolo
 Abeni" <pabeni@...hat.com>, Richard Cochran <richardcochran@...il.com>,
	"Jesse Brandeburg" <jbrandeburg@...udflare.com>
Subject: Re: [PATCH intel-next v1] ice: be consistent around PTP
 de-registration



On 4/7/2025 4:20 PM, Jesse Brandeburg wrote:

iwl-next, not intel-next :)

> From: Jesse Brandeburg <jbrandeburg@...udflare.com>
> 
> The driver was being inconsistent when de-registering its PTP clock. Make
> sure to NULL out the pointer once it is freed in all cases. The driver was
> mostly already doing so, but a couple spots were missed.
> 
> Signed-off-by: Jesse Brandeburg <jbrandeburg@...udflare.com>
> ---
> NOTE: we saw some odd behavior on one or two machines where the ports
> completed init, PTP completed init, then port 0 was "hot removed" via
> sysfs, and later panics on ptp->index being 1 while being called by
> ethtool. This caused me to look over this area and see this inconsistency.
> I wasn't able to confirm any for-sure bug.
> ---
>   drivers/net/ethernet/intel/ice/ice_main.c | 5 ++++-
>   drivers/net/ethernet/intel/ice/ice_ptp.c  | 4 ++--
>   2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 049edeb60104..8c1b496e84ef 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -3968,8 +3968,11 @@ static void ice_deinit_pf(struct ice_pf *pf)
>   		pf->avail_rxqs = NULL;
>   	}
>   
> -	if (pf->ptp.clock)
> +	if (pf->ptp.clock) {
>   		ptp_clock_unregister(pf->ptp.clock);
> +		pf->ptp.clock = NULL;
> +	}
> +	pf->ptp.state = ICE_PTP_UNINIT;

Hi Jesse,

It looks like we get a proper removal/unregister in ice_ptp_release() 
which is called from ice_deinit_features(). From what I'm seeing, I 
don't think the unregister should be done here at all.

Thanks,
Tony

>   
>   	xa_destroy(&pf->dyn_ports);
>   	xa_destroy(&pf->sf_nums);