netdev - RE: [PATCH iwl-net] ice: fix PTP cleanup on driver removal in error path

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: <IA1PR11MB62194EE66AD471C23925643992E1A@IA1PR11MB6219.namprd11.prod.outlook.com>
Date: Wed, 8 Oct 2025 15:21:20 +0000
From: "Nitka, Grzegorz" <grzegorz.nitka@...el.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Loktionov, Aleksandr"
	<aleksandr.loktionov@...el.com>, "Kitszel, Przemyslaw"
	<przemyslaw.kitszel@...el.com>
Subject: RE: [PATCH iwl-net] ice: fix PTP cleanup on driver removal in error
 path

> -----Original Message-----
> From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
> Sent: Wednesday, October 8, 2025 3:39 PM
> To: Nitka, Grzegorz <grzegorz.nitka@...el.com>; intel-wired-
> lan@...ts.osuosl.org
> Cc: netdev@...r.kernel.org; Loktionov, Aleksandr
> <aleksandr.loktionov@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>
> Subject: Re: [PATCH iwl-net] ice: fix PTP cleanup on driver removal in error
> path
> 
> On 08/10/2025 12:58, Grzegorz Nitka wrote:
> > Improve PTP feature cleanup in error path by adding explicit call to
> > ice_ptp_cleanup_pf in the case in which PTP feature is not fully
> > operational at the time of driver removal (which is indicated by
> > ptp->state flag).
> > At the driver probe, if PTP feature is supported, each PF adds its own
> > port to the list of ports controlled by ice_adapter object.
> > Analogously, at the driver remove, it's expected each PF is
> > responsible for removing previously added port from the list.
> > If for some reason (like errors in reset handling, NVM update etc.), PTP
> > feature has not rebuilt successfully, the driver is still responsible for
> > proper clearing ice_adapter port list. It's done by calling
> > ice_ptp_cleanup_pf function.
> > Otherwise, the following call trace is observed when ice_adapter object
> > is freed (port list is not empty, as it is expected at this stage):
> >
> > [  T93022] ------------[ cut here ]------------
> > [  T93022] WARNING: CPU: 10 PID: 93022 at
> > ice/ice_adapter.c:67 ice_adapter_put+0xef/0x100 [ice]
> > ...
> > [  T93022] RIP: 0010:ice_adapter_put+0xef/0x100 [ice]
> > ...
> > [  T93022] Call Trace:
> > [  T93022]  <TASK>
> > [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
> > 33d2647ad4f6d866d41eefff1806df37c68aef0c]
> > [  T93022]  ? __warn.cold+0xb0/0x10e
> > [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
> > 33d2647ad4f6d866d41eefff1806df37c68aef0c]
> > [  T93022]  ? report_bug+0xd8/0x150
> > [  T93022]  ? handle_bug+0xe9/0x110
> > [  T93022]  ? exc_invalid_op+0x17/0x70
> > [  T93022]  ? asm_exc_invalid_op+0x1a/0x20
> > [  T93022]  ? ice_adapter_put+0xef/0x100 [ice
> > 33d2647ad4f6d866d41eefff1806df37c68aef0c]
> > [  T93022]  pci_device_remove+0x42/0xb0
> > [  T93022]  device_release_driver_internal+0x19f/0x200
> > [  T93022]  driver_detach+0x48/0x90
> > [  T93022]  bus_remove_driver+0x70/0xf0
> > [  T93022]  pci_unregister_driver+0x42/0xb0
> > [  T93022]  ice_module_exit+0x10/0xdb0 [ice
> > 33d2647ad4f6d866d41eefff1806df37c68aef0c]
> > ...
> > [  T93022] ---[ end trace 0000000000000000 ]---
> > [  T93022] ice: module unloaded
> >
> > Fixes: e800654e85b5 ("ice: Use ice_adapter for PTP shared data instead of
> auxdev")
> > Signed-off-by: Grzegorz Nitka <grzegorz.nitka@...el.com>
> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
> > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> > ---
> >   drivers/net/ethernet/intel/ice/ice_ptp.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c
> b/drivers/net/ethernet/intel/ice/ice_ptp.c
> > index fb0f6365a6d6..c43a7973d70f 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> > @@ -3282,8 +3282,10 @@ void ice_ptp_init(struct ice_pf *pf)
> >    */
> >   void ice_ptp_release(struct ice_pf *pf)
> >   {
> > -	if (pf->ptp.state != ICE_PTP_READY)
> > +	if (pf->ptp.state != ICE_PTP_READY) {
> > +		ice_ptp_cleanup_pf(pf);
> >   		return;
> > +	}
> >
> >   	pf->ptp.state = ICE_PTP_UNINIT;
> >
> 
> ice_ptp_cleanup_pf() removes ptp->port.list_node, which is inited in
> ice_ptp_setup_pf(), but ice_ptp_init() may fail before
> ice_ptp_setup_pf() is called, and it will keep pf->ptp.state =
> ICE_PTP_ERROR. the cleanup then will work on uninitialized data.
> 
> It looks like it's better to make proper clean up in ice_ptp_setup_pf()
> on error path rather then modify ice_ptp_cleanup_pf().

Thanks Vadim for your feedback.
Of course, you're right for this specific flow.
However, the init part is not the only case when sth might go wrong.
I think we won't avoid that cleanup in ptp_release().
Anyway, I'm going to improve init error path part as you suggested
and rethink what else/how can be improved in ice_ptp_release().