netdev - Re: [PATCH net-next v3] net: micrel: Change to receive timestamp in the frame for lan8841

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: <ZJMAN88XYA6drwfe@hoboy.vegasvil.org>
Date: Wed, 21 Jun 2023 06:50:47 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Horatiu Vultur <horatiu.vultur@...rochip.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, andrew@...n.ch, hkallweit1@...il.com,
	linux@...linux.org.uk, davem@...emloft.net, edumazet@...gle.com,
	pabeni@...hat.com
Subject: Re: [PATCH net-next v3] net: micrel: Change to receive timestamp in
 the frame for lan8841

On Tue, Jun 20, 2023 at 11:30:21AM -0700, Jakub Kicinski wrote:
> Richard, looks good?

Yes.

> I'm not sure if the settime handling is sufficient, some packets may
> still sneak thru both getting stamped with new value of time and use
> old upper bits and get stamped with old bits and use new upper.
> Can we disable timestamping, drain the queue, then change the time
> and enable stamping again?

This can happen with any driver.  The user space stack combines four
time stamps to calculate the PTP client/server offset.  When setting
the clock, some skbs might be in the kernel's Rx path with the "old"
timestamp.

The kernel doesn't track Rx skbs that have HW timestamps, and stopping
the MAC and then flushing _everything_ seems heavy handed to me.

In the user space PTP stack, setting the clock happens immediately
after Sync message reception.  For configurations with a very high
Sync rate, a linuxptp client has an option to skip a given number of
messages after setting the clock.  In this way you can avoid stale
timestamps by choosing a duration that is longer than the longest
frame residence time from MAC to kernel.

Thanks,
Richard