Re: [PATCH] timerfd: Support CLOCK_TAI

[Chris Down <chris@chrisdown.name>]

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.