Re: [PATCH] timerfd: Support CLOCK_TAI

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Mar 19 2026 at 17:05, Chris Down wrote:
>> Will this cause a silent API failure where the timer is never added to the
>> cancel list for CLOCK_TAI, meaning the timer won't be canceled during
>> administrative clock jumps?
>>
>> Additionally, if it were added, timerfd_clock_was_set and timerfd_canceled
>> hardcode the jump-detection check to ktime_mono_to_real(0). Does this miss
>> independent jumps in CLOCK_TAI caused by adjtimex(ADJ_TAI)?
>
> So, timerfd_setup_cancel() is currently restricted to CLOCK_REALTIME and 
> CLOCK_REALTIME_ALARM, so a CLOCK_TAI timerfd created by this patch will behave 
> like the other non-REALTIME timerfds here. The behaviour is that the flag is 
> accepted by timerfd_settime(), but no cancel on set tracking is armed and the 
> timer will not report ECANCELED on clock changes.

Which is wrong.

> So what Sashiko says does not block this patch, because the patch is only 
> lifting the timerfd_create() allowlist restriction. The underlying 
> hrtimer/k_clock paths already support basic CLOCK_TAI timerfds, which is what 
> this patch is enabling.

Your new friend Sashiko and me have to agree that we disagree.

> If we wanted TFD_TIMER_CANCEL_ON_SET support for CLOCK_TAI, that would need 
> separate work. As Sashiko also said, the current cancel detection is based on 
> ktime_mono_to_real(0) (that is, REALTIME movement) and would not be sufficient 
> for standalone TAI offset changes such as adjtimex(ADJ_TAI). So supporting 
> cancel on set for CLOCK_TAI is not just a matter of adding CLOCK_TAI to 
> timerfd_setup_cancel() and would require defining the desired semantics and 
> adding distinct change detection for TAI. That's a much bigger change and 
> discussion.

Q: What's the discusison required?

A: None. Because it's already well defined. 

Q: What's the big change?

A: Nothing. Because TAI changes are already propagated

Q: Did you actually look at the code?

A: No. You just paraphrased the output of an AI bot. Nice try.

> So let's leave this patch as is for now.

Correct. I moved it already into the not-for-merging bin and that's where
I'll leave it. I'm not merging half baked crap based on the lousiest
argument I've heard in a long time.

That said, I'm not afraid of AI itself, but of the humans using it the
wrong way.

Thanks,

        tglx