netdev - Re: [PATCH net-next v3] net: mvpp2: tai: warn once if we fail to update our timestamp

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: <Z3a-HOwAVyJGEg67@shell.armlinux.org.uk>
Date: Thu, 2 Jan 2025 16:26:04 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Richard Cochran <richardcochran@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>,
	Marcin Wojtas <marcin.s.wojtas@...il.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>,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next v3] net: mvpp2: tai: warn once if we fail to
 update our timestamp

On Fri, Dec 13, 2024 at 09:14:02PM -0800, Richard Cochran wrote:
> On Fri, Dec 13, 2024 at 04:34:06PM +0000, Russell King wrote:
> > The hardware timestamps for packets contain a truncated seconds field,
> > only containing two bits of seconds. In order to provide the full
> > number of seconds, we need to keep track of the full hardware clock by
> > reading it every two seconds.
> > 
> > However, if we fail to read the clock, we silently ignore the error.
> > Print a warning indicating that the PP2 TAI clock timestamps have
> > become unreliable.
> 
> Rather than printing a warning that user space might not read, why not
> set a flag and stop delivering time stamps until the upper bits are
> available once again?

If we fail to read the clock, that will be because the hardware didn't
respond to our request to read it, which means the hardware broke in
some way. We could make mvpp22_tai_tstamp() fail and not provide
timestamps until we have successfully read the HW clock, but we would
still want to print a warning to explain why HW timestamps vanish.

However, if this happens, then it also means that the gettimex64 PTP
clock ioctl will also fail, so I would suggest that the user would
find out about it anyway.

So, I don't think the extra complexity is worth doing.

This is to catch a spurious failure that may only affects an occasoinal
attempt to read the HW PTP time. Currently, we would never know,
because the kernel is currently completely silent if that were to ever
happen.

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