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

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

[Jesse Brandeburg]

From: Jesse Brandeburg <jbrandeburg@cloudflare.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@cloudflare.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;
 
 	xa_destroy(&pf->dyn_ports);
 	xa_destroy(&pf->sf_nums);
diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
index 1fd1ae03eb90..d7a5c3fb7948 100644
--- a/drivers/net/ethernet/intel/ice/ice_ptp.c
+++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
@@ -3407,9 +3407,9 @@ void ice_ptp_init(struct ice_pf *pf)
 
 err_exit:
 	/* If we registered a PTP clock, release it */
-	if (pf->ptp.clock) {
+	if (ptp->clock) {
 		ptp_clock_unregister(ptp->clock);
-		pf->ptp.clock = NULL;
+		ptp->clock = NULL;
 	}
 	ptp->state = ICE_PTP_ERROR;
 	dev_err(ice_pf_to_dev(pf), "PTP failed %d\n", err);
-- 
2.43.0

RE: [Intel-wired-lan] [PATCH intel-next v1] ice: be consistent around PTP de-registration

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Jesse Brandeburg
> Sent: Tuesday, April 8, 2025 1:20 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Dumazet, Eric
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Richard Cochran <richardcochran@gmail.com>;
> Brandeburg, Jesse <jbrandeburg@cloudflare.com>
> Subject: [Intel-wired-lan] [PATCH intel-next v1] ice: be consistent around PTP
> de-registration
> 
> From: Jesse Brandeburg <jbrandeburg@cloudflare.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@cloudflare.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.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;
> 
>  	xa_destroy(&pf->dyn_ports);
>  	xa_destroy(&pf->sf_nums);
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c
> b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index 1fd1ae03eb90..d7a5c3fb7948 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -3407,9 +3407,9 @@ void ice_ptp_init(struct ice_pf *pf)
> 
>  err_exit:
>  	/* If we registered a PTP clock, release it */
> -	if (pf->ptp.clock) {
> +	if (ptp->clock) {
>  		ptp_clock_unregister(ptp->clock);
> -		pf->ptp.clock = NULL;
> +		ptp->clock = NULL;
>  	}
>  	ptp->state = ICE_PTP_ERROR;
>  	dev_err(ice_pf_to_dev(pf), "PTP failed %d\n", err);
> --
> 2.43.0

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

[Tony Nguyen]

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

iwl-next, not intel-next :)

> From: Jesse Brandeburg <jbrandeburg@cloudflare.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@cloudflare.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);

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

[Jacob Keller]

On 4/9/2025 2:54 PM, Tony Nguyen wrote:
> 
> 
> On 4/7/2025 4:20 PM, Jesse Brandeburg wrote:
> 
> iwl-next, not intel-next :)
> 
>> From: Jesse Brandeburg <jbrandeburg@cloudflare.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@cloudflare.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
> 

+1, I think a v2 should just remove the entire call to
ptp_clock_unregister here. It's the wrong place to do it. It causing
problems is further evidence of this.

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

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

[Jesse Brandeburg]

On Wed, Apr 9, 2025 at 10:01 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> On 4/9/2025 2:54 PM, Tony Nguyen wrote:
> > On 4/7/2025 4:20 PM, Jesse Brandeburg wrote:
> >
> > iwl-next, not intel-next :)

The brain rot on unused cells is severe it seems :-)

> >> -    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
> >
>
> +1, I think a v2 should just remove the entire call to
> ptp_clock_unregister here. It's the wrong place to do it. It causing
> problems is further evidence of this.

Ok, thanks to both, I'll see if I can spin a v2 and eliminate the
extra cruft. This might also explain why a second load of the driver
fails to register the clock after the double unregister.