netdev - [PATCH net-next 0/2] ptp: safely cleanup when unregistering a 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-next>] [day] [month] [year] [list]

Message-ID: <aMglp11mUGk9PAvu@shell.armlinux.org.uk>
Date: Mon, 15 Sep 2025 15:41:43 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Richard Cochran <richardcochran@...il.com>
Cc: 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>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Vladimir Oltean <vladimir.oltean@....com>,
	Wei Fang <wei.fang@....com>, Yangbo Lu <yangbo.lu@....com>
Subject: [PATCH net-next 0/2] ptp: safely cleanup when unregistering a PTP
 clock

(I'm assuming drivers/ptp/ patches go via net-next as there is no
git tree against the "PTP HARDWARE CLOCK SUPPORT" maintainers entry.)

The standard rule in the kernel for unregistering user visible devices
is to unpublish the userspace API before doing any shutdown of the
resources necessary for the operation of the device.

PTP has several issues in this area:

1. ptp_clock_unregister() cancells and destroys work while the PTP
   chardev is still published, which gives the opportunity for a
   precisely timed user API call to cause a driver to attempt to
   queue the aux work.

2. PTP pins are not cleaned up - if userspace has enabled PTP pins,
   e.g. for extts, drivers are forced to do cleanup before calling
   ptp_clock_unregister() to stop events being forwarded into the
   PTP layer. E.g mv88e6xxx cancells its internal tai_event_work
   to avoid calling into the PTP clock code with a stale ptp_clock
   pointer, but a badly timed userspace EXTTS enable will re-schedule
   the tai_event_work.

Simplify the process by ensuring that:

1. we take a referene on the PTP struct device to stop the
   ptp_clock structure going away underneath us when we call
   posix_clock_unregister().

2. call posix_clock_unregister() to remove the /dev/ptp* device.

3. add additional functionality to disable any PTP pins that have
   been configured on this device. This should shutdown all events
   coming from PTP clock drivers.

4. cancel the delayed aux_work and destroy the kthread.

5. remove the PPS source.

6. drop the reference on the PTP struct device to allow the
   ptp_clock structure to be released.

This is difficult for me to test beyond build testing - on the
Clearfog platform with Marvell PHY PTP, the ethernet PHY is the
primary connectivity, so removing the PHY driver for an in-use
network interface isn't possible.

On the ZII rev B platform, where the DSA switches have the TAI
hardware and where root NFS is used, removal of the DSA switch
module somehow forces the FEC interface _not_ connected to the DSA
switch to lose link, causing the machine to become unresponsive
as its root filesystem vanishes.

 drivers/ptp/ptp_chardev.c | 21 ++++++++++++++++++++-
 drivers/ptp/ptp_clock.c   | 17 ++++++++++++++++-
 drivers/ptp/ptp_private.h |  2 ++
 3 files changed, 38 insertions(+), 2 deletions(-)

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