netdev - Re: [PATCH net-next 2/2] ptp: rework ptp_clock

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: <aMnVBgMG3Nnjgr8E@shell.armlinux.org.uk>
Date: Tue, 16 Sep 2025 22:22:14 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Richard Cochran <richardcochran@...il.com>,
	Ajay Kaher <ajay.kaher@...adcom.com>,
	Alexey Makhalov <alexey.makhalov@...adcom.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
	Clark Wang <xiaoning.wang@....com>,
	"David S. Miller" <davem@...emloft.net>,
	David Woodhouse <dwmw2@...radead.org>,
	Eric Dumazet <edumazet@...gle.com>, imx@...ts.linux.dev,
	Jakub Kicinski <kuba@...nel.org>,
	Jonathan Lemon <jonathan.lemon@...il.com>, netdev@...r.kernel.org,
	Nick Shi <nick.shi@...adcom.com>, Paolo Abeni <pabeni@...hat.com>,
	Sven Schnelle <svens@...ux.ibm.com>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Wei Fang <wei.fang@....com>, Yangbo Lu <yangbo.lu@....com>
Subject: Re: [PATCH net-next 2/2] ptp: rework ptp_clock_unregister() to
 disable events

On Tue, Sep 16, 2025 at 08:46:28PM +0100, Russell King (Oracle) wrote:
> On Tue, Sep 16, 2025 at 05:20:19PM +0100, Vadim Fedorenko wrote:
> > On 16/09/2025 16:45, Russell King (Oracle) wrote:
> > > Having used NTP with a PPS sourced from a GPS, I'd personally want
> > > the PPS to stop if the GPS is no longer synchronised, so NTP knows
> > > that a fault has occurred, rather than PPS continuing but being
> > > undiscplined and thus of unknown accuracy.
> > > 
> > > I'd suggest that whether PPS continues to be generated should be a
> > > matter of user policy. I would suggest that policy should include
> > > whether or not userspace is discplining the clock - in other words,
> > > whether the /dev/ptp* device is open or not.
> > 
> > The deduction based on the amount of references to ptp device is not
> > quite correct. Another option is to introduce another flag and use it
> > as a signal to remove the function in case of error/shutdown/etc.
> > > Consider the case where the userspace daemons get OOM-killed and
> > > that isn't realised. The PPS signal continues to be generated but
> > > is now unsynchronised and drifts. Yet PPS users continue to
> > > believe it's accurate.
> > 
> > And again, there is another use-case which actually needs thisunsynchronised
> > signal
> 
> For my use case (Marvell platforms) we only support EXTTS there, so I'm
> happy to restrict this behaviour to EXTTS. If drivers need e.g. timers
> or workqueues to support the other pin functions, then this will need
> to be revisited so they can safely tear down their software resources.

I think I've missed another source of trouble here: PPS input, enabled
via PTP_CLK_REQ_PPS, which seems to be a purely software construct
where the hardware triggers e.g. an interrupt to forward a PPS event.

As this is not a pin, this doesn't get disabled. This is subject to
all the same race conditions that EXTTS is subject to, so I think
ptp_unregister_clock() needs to deal with this too.

New patches on their way shortly...

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!