fix(timer): support CLOCK_REALTIME in timer_create

[mistcoversmyeyes]

Problem

GNU coreutils timeout fails on DragonOS because it creates its POSIX timer with CLOCK_REALTIME:

timeout: warning: timer_create: Invalid argument

This warning was observed while running the LMbench TCP loopback latency wrapper under QEMU, but it is intermittently observable through that path: on some runs timeout succeeds via a fallback and the wrapper completes without the warning. The underlying kernel limitation is deterministic and is best reproduced with the C API below.

Authoritative reproduction (C API, confirmed in guest)

Run the following inside a DragonOS guest (not on the Linux host):

#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <time.h>

static void try_timer(clockid_t clock_id, const char *name)
{
    timer_t timer_id;

    if (timer_create(clock_id, NULL, &timer_id) == 0) {
        printf("%s: OK\n", name);
        timer_delete(timer_id);
        return;
    }

    printf("%s: failed: errno=%d (%s)\n",
           name, errno, strerror(errno));
}

int main(void)
{
    try_timer(CLOCK_MONOTONIC, "CLOCK_MONOTONIC");
    try_timer(CLOCK_REALTIME, "CLOCK_REALTIME");
    return 0;
}

Cross-compile for the guest (x86_64, glibc 2.39) and run on the guest. Confirmed output on DragonOS x86_64/QEMU:

CLOCK_MONOTONIC: OK
CLOCK_REALTIME: failed: errno=22 (Invalid argument)

So timer_create(CLOCK_REALTIME, NULL, &timerid) deterministically returns EINVAL. With sevp == NULL, this is the standard default SIGEV_SIGNAL / SIGALRM behavior; it does not require SIGEV_THREAD.

Secondary reproduction (coreutils timeout)

Inside a DragonOS guest:

/usr/local/bin/timeout 1s /bin/true 2>&1
echo "exit=$?"

May print timeout: warning: timer_create: Invalid argument (intermittent; timeout can still complete via fallback). The LMbench end-to-end path is:

make test-benchmark
grep -n -C 3 "timer_create: Invalid argument" serial_opt.txt

The warning, when present, appears in the tcp_loopback_lat case; lat_tcp can still print a numeric latency, and the benchmark runner may accept that sample.

Root cause

kernel/src/process/posix_timer.rs currently accepts only CLOCK_MONOTONIC in timer_create, returning EINVAL for CLOCK_REALTIME. GNU coreutils calls:

timer_create(CLOCK_REALTIME, NULL, &timerid)

Expected behavior

timer_create(CLOCK_REALTIME, NULL, &timerid) should succeed when the requested notification mode is already supported, so standard coreutils timeout works.

Scope

Supporting CLOCK_REALTIME alongside the existing CLOCK_MONOTONIC path should be sufficient for this compatibility case. Timer semantics should follow the selected clock and preserve the existing notification behavior.

Related work checked

• PR feat(kernel/posix-timer): 实现 POSIX interval timer，修复 gVisor timers_test #1501: POSIX timer implementation
• PR fix(process): 修正POSIX定时器信号投递逻辑并支持SIGEV_THREAD #1521: SIGEV_THREAD / SIGEV_THREAD_ID
• PR fix(timekeeping): restore monotonic clock and clocksource semantics #2145: timekeeping semantics
• Issue ci: investigate intermittent gVisor test timeouts #2085: intermittent gVisor timeout
• Issue [Userland] 尝试引入uutils/coreutils替代现有用户空间命令 #1146: coreutils discussion

None appears to cover rejecting CLOCK_REALTIME in timer_create.

Environment

• DragonOS x86_64 in QEMU (KVM)
• GNU coreutils timeout
• LMbench 3.0-a9 TCP loopback latency benchmark
• Guest glibc 2.39, x86_64-linux-gnu cross-compiled repro binary