netdev - Re: [PATCH net-next v2 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMrKB2qDCTXURtxj@hoboy.vegasvil.org>
Date: Wed, 17 Sep 2025 07:47:35 -0700
From: Richard Cochran <richardcochran@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
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: Re: [PATCH net-next v2 0/2] ptp: safely cleanup when unregistering a
 PTP clock

On Tue, Sep 16, 2025 at 10:35:30PM +0100, Russell King (Oracle) wrote:
> (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.

Thanks, Russell!

For the series:

Acked-by: Richard Cochran <richardcochran@...il.com>