netdev - Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET

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: <Z3a892mBOSRl6BlN@hoboy.vegasvil.org>
Date: Thu, 2 Jan 2025 08:21:11 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Peter Hilber <quic_philber@...cinc.com>
Cc: linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
	virtio-dev@...ts.linux.dev, netdev@...r.kernel.org,
	Trilok Soni <quic_tsoni@...cinc.com>,
	Srivatsa Vaddagiri <quic_svaddagi@...cinc.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eugenio Pérez <eperezma@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	Andrew Lunn <andrew+netdev@...n.ch>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Jason Wang <jasowang@...hat.com>,
	Paolo Abeni <pabeni@...hat.com>, Shuah Khan <shuah@...nel.org>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	linux-kselftest@...r.kernel.org, linux-api@...r.kernel.org,
	David Woodhouse <dwmw2@...radead.org>,
	"Ridoux, Julien" <ridouxj@...zon.com>,
	John Stultz <jstultz@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Stephen Boyd <sboyd@...nel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Re: [RFC PATCH 1/2] ptp: add PTP_SYS_OFFSET_STAT for xtstamping with
 status

On Thu, Jan 02, 2025 at 05:11:01PM +0100, Peter Hilber wrote:
> Would it be more acceptable to just announce leap seconds, but not
> whether to smear?

Up until now, leap second announcements were handled in user space,
and the kernel played no role.

> I do not understand. Is the point that guests should decide through
> another channel about leap second smearing?

Yes, that would make more sense to me.

> I hope there will be some feedback from third parties (at least related
> to virtualization).

+1

I'm no VM expert, but I'd like to avoid tacking things onto the kernel
PTP layer, unless there is a really strong justification.

> For sure. But the aim of this proposal is to have an interoperable time
> synchronization solution for VMs through a Virtio device. So the idea is
> to include metrics, if a consensus on their usefulness can be reached.
> AFAIU it is difficult to bypass the kernel for Virtio devices.

Providing clock metrics only makes sense when there is some choice to
be made based on those metrics.  If the "limited" VM guests don't even
have networking, then they have no choice but to accept the time from
the VM host, right?  In which case, the metrics do not provide any
benefit to the guest.

Or what am I missing?

Thanks,
Richard