{"id":2220895,"url":"http://patchwork.ozlabs.org/api/1.1/covers/2220895/?format=json","web_url":"http://patchwork.ozlabs.org/project/netfilter-devel/cover/20260408102356.783133335@kernel.org/","project":{"id":26,"url":"http://patchwork.ozlabs.org/api/1.1/projects/26/?format=json","name":"Netfilter Development","link_name":"netfilter-devel","list_id":"netfilter-devel.vger.kernel.org","list_email":"netfilter-devel@vger.kernel.org","web_url":null,"scm_url":null,"webscm_url":null},"msgid":"<20260408102356.783133335@kernel.org>","date":"2026-04-08T11:53:41","name":"[V2,00/11] hrtimers: Prevent hrtimer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/1.1/people/92397/?format=json","name":"Thomas Gleixner","email":"tglx@kernel.org"},"mbox":"http://patchwork.ozlabs.org/project/netfilter-devel/cover/20260408102356.783133335@kernel.org/mbox/","series":[{"id":499126,"url":"http://patchwork.ozlabs.org/api/1.1/series/499126/?format=json","web_url":"http://patchwork.ozlabs.org/project/netfilter-devel/list/?series=499126","date":"2026-04-08T11:53:41","name":"hrtimers: Prevent hrtimer interrupt starvation","version":2,"mbox":"http://patchwork.ozlabs.org/series/499126/mbox/"}],"comments":"http://patchwork.ozlabs.org/api/covers/2220895/comments/","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","netfilter-devel@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=lsGJ/oyO;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c04:e001:36c::12fc:5321; helo=tor.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11713-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=\"lsGJ/oyO\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org\n [IPv6:2600:3c04:e001:36c::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frM162M1rz1xy1\n\tfor ; Wed, 08 Apr 2026 21:54:18 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby tor.lore.kernel.org (Postfix) with ESMTP id C439530616FE\n\tfor ; Wed, 8 Apr 2026 11:53:50 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A9DD83B583C;\n\tWed, 8 Apr 2026 11:53:45 +0000 (UTC)","from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org\n [10.30.226.201])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E69C38C434;\n\tWed, 8 Apr 2026 11:53:44 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 11E08C19421;\n\tWed, 8 Apr 2026 11:53:43 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775649225; cv=none;\n b=S9intXw45/HmCToV4U6vQKJpPw/9QWjbi4wgZavltOcf2Fx5iXn0xTn1tmIETL056CsCGQl8B8+AX/+4KpsbISlZjv3wWOnO4HBQ5ZI2e7LY+vbDNQsMCQ2bxR4SmwZMy64PWQPx/Ea0oQmdDmTvw2HwQr0xT0MLDXeyXM8vP1Y=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775649225; c=relaxed/simple;\n\tbh=7Psi4PCmg4NxRRGlQRXmH+F3BN6jVuP2qTBx5cq2iQE=;\n\th=Date:Message-ID:From:To:Subject:cc;\n b=RkYI5fBn4bfjJ7iyapi+N0Dab1hru6CRFM076YPTtrvTyjyUFqyvz+BdqmYp1ecWJRsJ+2yyLIQcWP8t6lmB2ZudsTLqjRehKQooXCWQqRiio84ISeDzWYhhmFEsTD2rDwE27lsc+l2o8Zdiiac++aTlpsgGBbudH/92yBfeikQ=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org\n header.b=lsGJ/oyO; arc=none smtp.client-ip=10.30.226.201","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1775649224;\n\tbh=7Psi4PCmg4NxRRGlQRXmH+F3BN6jVuP2qTBx5cq2iQE=;\n\th=Date:From:To:Subject:cc:From;\n\tb=lsGJ/oyOvX6cfoHwkNDEvgoFQSDMESpcA7Am+qQqDX+ZczSfpk7BYkv1wxn/o+Y6x\n\t uV70JUMAWZQzZVTa4JXQVPgruXx8VEkY8kRAOSxt/0U9/KY79XCbOCWoa36mOHp++n\n\t cLbbn5Yp/9dKUFYtiPGRKT+LzTESjO0um/rXgHWuKcDcgp0caxdQcg1ivEDbv+MuTG\n\t R5m9V1pZUDtUZsq/xIGGTNooKNCKPEGayFkS2CC7P20z5WN3bdaMCQhUtBzOUDptor\n\t sfAxoAJoNL62cfrL/HoXNfnC8F0A/KeFxL4x5SUIQNk8vw11q+9jO2TOfsdK0yIPQm\n\t TyhVHe5A8x0Bw==","Date":"Wed, 08 Apr 2026 13:53:41 +0200","Message-ID":"<20260408102356.783133335@kernel.org>","User-Agent":"quilt/0.68","From":"Thomas Gleixner ","To":"LKML ","Subject":"[patch V2 00/11] hrtimers: Prevent hrtimer interrupt starvation","cc":"Calvin Owens ,\n Anna-Maria Behnsen ,\n Frederic Weisbecker ,\n \"Peter Zijlstra (Intel)\" ,\n John Stultz ,\n Stephen Boyd ,\n Alexander Viro ,\n Christian Brauner ,\n Jan Kara ,\n linux-fsdevel@vger.kernel.org,\n Sebastian Reichel ,\n linux-pm@vger.kernel.org,\n Pablo Neira Ayuso ,\n Florian Westphal ,\n Phil Sutter ,\n netfilter-devel@vger.kernel.org,\n coreteam@netfilter.org","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":""},"content":"This is a follow up to V1 which can be found here:\n\n https://lore.kernel.org/lkml/20260407083219.478203185@kernel.org\n\nCalvin reported an odd NMI watchdog lockup which claims that the CPU locked\nup in user space:\n\n https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n\nHe provided a reproducer, which sets up a timerfd based timer and then\nrearms it in a loop with an absolute expiry time of 1ns.\n\nAs the expiry time is in the past, the timer ends up as the first expiring\ntimer in the per CPU hrtimer base and the clockevent device is programmed\nwith the minimum delta value. If the machine is fast enough, this ends up\nin a endless loop of programming the delta value to the minimum value\ndefined by the clock event device, before the timer interrupt can fire,\nwhich starves the interrupt and consequently triggers the lockup detector\nbecause the hrtimer callback of the lockup mechanism is never invoked.\n\nThe first patch in the V1 series changes the clockevent set next event\nmechanism to prevent reprogramming of the clockevent device when the\nminimum delta value was programmed unless the new delta is larger than\nthat. It's a less convoluted variant of the patch which was posted in the\nabove linked thread and was confirmed to prevent the starvation problem.\n\nBut that's only to be considered the last resort because it results in an\ninsane amount of avoidable hrtimer interrupts. That patch has been merged\ninto the tip tree already.\n\nThe problem of user controlled timers is that the input value is only\nsanity checked vs. validity of the provided timespec and clamped to be in\nthe maximum allowable range. But for performance reasons for in kernel\nusage there is no check whether a to be armed timer might have been expired\nalready at enqueue time.\n\nThis series addresses this by providing a separate interface to arm user\ncontrolled timers. This works the same way as the existing\nhrtimer_start_range_ns(), but in case that the timer ends up as the first\ntimer in the clock base after enqueue it provides additional checks:\n\n - Whether the timer becomes the first expiring timer in the CPU base.\n\n \tIf not the timer is considered to expire in the future as there is\n\talready an earlier event programmed.\n\n - Whether the timer has expired already by comparing the expiry value\n against current time.\n\n\tIf it is expired, the timer is removed from the clock base and the\n\tfunction returns false, so that the caller can handle it. That's\n\trequired because the function cannot invoke the callback as that\n\tmight need to acquire a lock which is held by the caller.\n\nThis function is then used for the user controlled timer arming interfaces\nmainly by converting hrtimer sleeper over to it. That affects a few in\nkernel users too, but the overhead is minimal in that case and it spares a\ntedious whack the mole game all over the tree.\n\nThe other usage sites in posixtimers, alarmtimers and timerfd are converted\nas well, which should cover the vast majority of user space controllable\ntimers as far as my investigation goes.\n\nChanges vs. V1:\n\n - Dropped the clockevents patch as it is already merged\n\n - Rebased on tip timers/core\n\n - Moved the user check into hrtimer_start_range_ns_user() - Peter\n\n - Renamed alarmtimer_start() to alarm_start_timer() - Peter\n\n - Picked up tags as appropriate\n \nThe series applies against tip timers/core and is also available from git:\n\n git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git hrtimer-exp-v2\n\nThanks,\n\n\ttglx\n---\n drivers/power/supply/charger-manager.c | 12 +-\n fs/timerfd.c | 117 ++++++++++++++++-----------\n include/linux/alarmtimer.h | 9 +-\n include/linux/hrtimer.h | 20 ++++\n include/trace/events/timer.h | 13 +++\n kernel/time/alarmtimer.c | 70 +++++++---------\n kernel/time/hrtimer.c | 140 ++++++++++++++++++++++++++++-----\n kernel/time/posix-cpu-timers.c | 18 ++--\n kernel/time/posix-timers.c | 35 +++++---\n kernel/time/posix-timers.h | 4 \n net/netfilter/xt_IDLETIMER.c | 24 ++++-\n 11 files changed, 320 insertions(+), 142 deletions(-)"}