netdev - Re: [Intel-wired-lan] [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: <8580a516-0bf0-49f0-9431-cb8f79fc4f83@intel.com>
Date: Wed, 9 Apr 2025 22:00:56 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: Tony Nguyen <anthony.l.nguyen@...el.com>, 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: [Intel-wired-lan] [PATCH intel-next v1] ice: be consistent around
 PTP de-registration



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@...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
> 

+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);