Re: [BUG] Random hard lockup with userspace %ip on 7.0-rc5

[Thomas Gleixner <tglx@kernel.org>]

On Tue, Mar 31 2026 at 18:58, Calvin Owens wrote:
> On Wednesday 03/25 at 17:56 +0100, Thomas Gleixner wrote:
> The below userspace reproducer consistently triggers the hard lockup
> on two different machines with an AMD 7950X3D and an AMD 9950X3D CPU.

Is that instantaneous or does it take some time?

> However, it never reproduces at all on a Xeon E-2124. Maybe a clue?

Not really, but there is a difference in how the timer hardware is
programmed. The XEON uses the TSC deadline timer, the AMD CPUs use the
good old local APIC timer. But you can disable the deadline timer on the
XEON with 'notscdeadline' on the kernel command line.

> I wish I had a nice clever story for how I found it, but I just guessed
> based on how systemd uses timerfd_settime().

:)

> #ifndef NR_THREADS
> #define NR_THREADS 32
> #endif
>
> static void set(int fd)
> {
> 	struct itimerspec new = {
> 		.it_value = {
> 			.tv_sec = 0,
> 			.tv_nsec = 1,
> 		},
> 	};
>
> 	if (timerfd_settime(fd, TFD_TIMER_ABSTIME | TFD_TIMER_CANCEL_ON_SET,
> 			    &new, NULL))
> 		err(2, "Can't set timer");

So this [re]starts the timer which immediately expires. Most likely even
before the syscall returns. TFD_TIMER_CANCEL_ON_SET has no effect
because the timer is based on CLOCK_MONOTONIC, which cannot be set.

> static void *fn(void *arg)
> {
> 	int fd = timerfd_create(CLOCK_MONOTONIC, 0);
>
> 	while (1)
> 		set(fd);

and does so in an endless loop with NR_THREADS in parallel. That means
all 32 CPUs are hogged by this. But the scheduler has full control of
the tasks, so there is no real good explanation why the machine would
actually lock up.

Now that you have a reproducer, can you verify that the machine really
locks up hard? Disable the NMI watchdog either via the kernel command
line 'nmi_watchdog=0' or via echo 0 >/proc/sys/kernel/nmi_watchdog.

If that works and the machine stays usable then the watchdog is
hallucinating.

Thanks,

        tglx