Re: [patch 09/24] timekeeping: Add CLOCK_AUX support for ktime_get_snapshot_id()

[David Woodhouse]

On Fri, 2026-06-26 at 10:48 +0200, Thomas Weißschuh wrote:
> 'tkd' is also used to compute 'monoraw'. However 'tkr_raw' and 'tkr_mono'
> are the same for auxilary clocks, so this will compute a wrong 'monoraw'.
> Instead 'monoraw' should be computed based on 'tk_core'.
> Which then also requires the sequence locking of 'tk_core'.
> 
> As you know I have a series which unifies the locking between the
> different timekeepers. Maybe we revert this patch for 7.2 and I send
> a fixed variant including the prerequisites for 7.3.
> 
> (The same goes for get_device_system_crosststamp())

No fundamental objection from me... but does it matter in practice?
Is it even reachable?

I think the only way these functions can end up being invoked for aux
clocks is via PTP_SYS_OFFSET_EXTENDED, which since commit a6d799608e6
("ptp: Switch to ktime_get_snapshot_id() for pre/post timestamps") and
some other driver-specific changes in this series, can now invoke them
with the user-requested clockid.

But those callers *only* care about ::systime, don't they? So the
problem never arises because there's no code path in which anything
actually cares about ::monoraw for AUX clocks.

If we back out the handling of AUX clocks in ktime_get_snapshot_id()
we'd have to roll back much of that other plumbing too. If we *just*
remove the 'case CLOCK_AUX ... CLOCK_AUX_LAST' hunk, we'd end up with
users being able to trigger the 'default: WARN_ON_ONCE(1)' which
follows.

So while you're right, I *think* it's harmless in practice and
reverting it safely is slightly more complex than it seems at first
glance?

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