Re: [PATCH net-next v8 3/3] gve: implement PTP gettimex64

[David Woodhouse]

On Wed, 2026-05-20 at 23:08 +0200, Thomas Gleixner wrote:
> 
> But what's worse and escaped the AI scrutiny is:
> 
>   Your attempt to convert these 'get_cycles()' time stamps after the
>   fact and outside of the timekeeping core protection is fundamentally
>   wrong.
> 
> get_device_system_crosststamp() does
> 
>       do {
>       		seq = read_seqcount_begin(&tk_core.seq);
>                 take_timestamps(...);
>                 convert_timestamps(...)
>       } while (read_seqcount_retry(&tk_core.seq, seq));
> 
> which covers the whole sequence of taking the snapshots from the
> hardware and the conversion.
> 
> Your abuse of this is completely out of spec. Just because it did not
> blow up in your face yet does not make it in any way correct. You do not
> even get bonus points for creative abuse.

I'm not sure I concur. As I understand it, the requirement is that the
time stamp must be after the snapshot passed in to
get_device_system_crosststamp() as its 'history_begin' argument.

Not that the time stamp is literally within the do{} loop you mention.

That loop literally has:

		interval_start = tk->tkr_mono.cycle_last;
		if (!timestamp_in_interval(interval_start, now, cycles)) {
			...
			do_interp = true;

...which triggers the whole adjust_historical_crosststamp() thing
further down, *none* of which would have any reason to exist if what
you say above is true, surely?

Attachment: smime.p7s
Description: S/MIME cryptographic signature