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] [day] [month] [year] [list]

Message-ID: <CAB1XECUHTeA30j=NpLSQxTNx-KFaDzo55Bksj9UCZg=pHHNCCw@mail.gmail.com>
Date: Thu, 10 Apr 2025 15:28:47 -0700
From: Jesse Brandeburg <jbrandeburg@...udflare.com>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: Tony Nguyen <anthony.l.nguyen@...el.com>, Jesse Brandeburg <jbrandeb@...nel.org>, 
	intel-wired-lan@...ts.osuosl.org, 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>
Subject: Re: [Intel-wired-lan] [PATCH intel-next v1] ice: be consistent around
 PTP de-registration

On Wed, Apr 9, 2025 at 10:01 PM Jacob Keller <jacob.e.keller@...el.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.