[PATCH] timerfd: Support CLOCK_TAI

[PATCH] timerfd: Support CLOCK_TAI

[Chris Down]

Despite hrtimer and POSIX timers both accepting CLOCK_TAI,
timerfd_create() rejects it. This usually corners userspace into one of
two bad options:

1. Convert TAI deadlines through CLOCK_REALTIME, which reintroduces the
   leap second exposure the application was trying to avoid in the first
   place.
2. Abandon timerfd entirely and use POSIX timers or busy wait approaches
   that do not compose well with epoll based event loops.

Avoid these bad outcomes by allowing timerfd to support CLOCK_TAI. The
underlying hrtimer and k_clock infrastructure already supports this.

With this, epoll based applications can arm TAI based file descriptor
timers natively.

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 fs/timerfd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/timerfd.c b/fs/timerfd.c
index 73104f36bcae..278ad4ab65c8 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -404,6 +404,7 @@ SYSCALL_DEFINE2(timerfd_create, int, clockid, int, flags)
 	    (clockid != CLOCK_MONOTONIC &&
 	     clockid != CLOCK_REALTIME &&
 	     clockid != CLOCK_REALTIME_ALARM &&
+	     clockid != CLOCK_TAI &&
 	     clockid != CLOCK_BOOTTIME &&
 	     clockid != CLOCK_BOOTTIME_ALARM))
 		return -EINVAL;

base-commit: a989fde763f4f24209e4702f50a45be572340e68
-- 
2.53.0

Re: [PATCH] timerfd: Support CLOCK_TAI

[Chris Down]

To proactively reply to what Sashiko said in 
https://sashiko.dev/#/patchset/abuTTv9FC__H_8RC%40chrisdown.name:

> If a user creates a CLOCK_TAI timer and later calls timerfd_settime with
> the TFD_TIMER_CANCEL_ON_SET flag, does the kernel silently ignore the flag?
>
> Looking at timerfd_setup_cancel in fs/timerfd.c, the cancellation logic
> appears to be explicitly restricted to CLOCK_REALTIME and
> CLOCK_REALTIME_ALARM:
>
> static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags)
> {
>         ...
>         if ((ctx->clockid == CLOCK_REALTIME ||
>              ctx->clockid == CLOCK_REALTIME_ALARM) &&
>             (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
>                 ...
>         } else {
>                 __timerfd_remove_cancel(ctx);
>         }
> }
>
> 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.

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.

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.

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

Re: [PATCH] timerfd: Support CLOCK_TAI

[Thomas Gleixner]

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