[{"id":3674858,"web_url":"http://patchwork.ozlabs.org/comment/3674858/","msgid":"<adaH_AVmNLlRd3ep@localhost.localdomain>","list_archive_url":null,"date":"2026-04-08T16:53:16","subject":"Re: [patch V2 01/11] hrtimer: Provide hrtimer_start_range_ns_user()","submitter":{"id":79411,"url":"http://patchwork.ozlabs.org/api/people/79411/","name":"Frederic Weisbecker","email":"frederic@kernel.org"},"content":"Le Wed, Apr 08, 2026 at 01:53:46PM +0200, Thomas Gleixner a écrit :\n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which set's up a timerfd based\n> timer and then rearms it in a loop with an absolute expiry time of 1ns.\n> \n> As the expiry time is in the past, the timer ends up as the first expiring\n> timer in the per CPU hrtimer base and the clockevent device is programmed\n> with the minimum delta value. If the machine is fast enough, this ends up\n> in a endless loop of programming the delta value to the minimum value\n> defined by the clock event device, before the timer interrupt can fire,\n> which starves the interrupt and consequently triggers the lockup detector\n> because the hrtimer callback of the lockup mechanism is never invoked.\n> \n> The clockevents code already has a last resort mechanism to prevent that,\n> but it's sensible to catch such issues before trying to reprogram the clock\n> event device.\n> \n> Provide a variant of hrtimer_start_range_ns(), which sanity checks the\n> timer after queueing it. It does not so before because the timer might be\n> armed and therefore needs to be dequeued. also we optimize for the latest\n> possible point to check, so that the clock event prevention is avoided as\n> much as possible.\n> \n> If the timer is already expired _before_ the clock event is reprogrammed,\n> remove the timer from the queue and signal to the caller that the operation\n> failed by returning false.\n> \n> That allows the caller to take immediate action without going through the\n> loops and hoops of the hrtimer interrupt.\n> \n> The queueing code can't invoke the timer callback as the caller might hold\n> a lock which is taken in the callback.\n> \n> Add a tracepoint which allows to analyze the expired at start situation.\n> \n> Reported-by: Calvin Owens <calvin@wbinvd.org>\n> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n> Cc: Frederic Weisbecker <frederic@kernel.org>\n\nReviewed-by: Frederic Weisbecker <frederic@kernel.org>","headers":{"Return-Path":"\n <netfilter-devel+bounces-11746-incoming=patchwork.ozlabs.org@vger.kernel.org>","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=eKj5Xyn4;\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-11746-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=\"eKj5Xyn4\"","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 4frTgX05KZz1xv0\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 09 Apr 2026 02:54:31 +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 73AF5306B518\n\tfor <incoming@patchwork.ozlabs.org>; Wed,  8 Apr 2026 16:53:26 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id D09543D47B3;\n\tWed,  8 Apr 2026 16:53:20 +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 5A9F13B3C11;\n\tWed,  8 Apr 2026 16:53:20 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 7FBADC19421;\n\tWed,  8 Apr 2026 16:53:19 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775667200; cv=none;\n b=ZWL1yA3IhSlnEZyOJKQUP7PfpJFAhi23USwepzbmnjFzUmWejjQk/ljzDCurEmXyCTHScQWRbrtHCvwNVHCWfGlXFJ5BV9hyrbl7BK4okhuBnXj38QWBWwTbtDeKvk/CG5wkcfZI1a4U5h+AjIQ6Pq3ANnOUX2KzZ5tK5aJ5XV0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775667200; c=relaxed/simple;\n\tbh=UHeo9KUp++AkJnjsJTxVP1fyHnDvaWVtuwwTMYh7KXc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=hc4fLm96T2XEO97BY6KuBOUJCJ6+yUt8vI20IzL0dcp3lQ2c2D9mCnzQ1J1WRXo4SS7/9YifztTAMClaAKhiaWiIfdGjORv3Y9BJavpWpHVD2zz19lYmdpG+3LezEzn5cNdEXncCJ2jsVqKBMidV/Lz4x98QvMUNTzb+4J3lWQ8=","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=eKj5Xyn4; 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=1775667200;\n\tbh=UHeo9KUp++AkJnjsJTxVP1fyHnDvaWVtuwwTMYh7KXc=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=eKj5Xyn44yw+/kc20bOe9qdOUnx5JhnFtYFLhBd78PWku/RJpIwHEXW6G2p+QUov9\n\t 25JNMovX8caRkCFarah5c7Qc/Dv+RC6rM4LKoRCe/iDYOiUezcM+HA73ze1CYgpPY2\n\t ir6dcAUOIYmS+cPqELdX3n2m1h2JDO+p2VmmMtgR7hmo6iOVc2OP6s5CBHCw/ipbOV\n\t ku0sYua9fnOqk+2PsvFgzzmFlE82njHeyXL3wEMJEg1IPxZSyy4ahHTJxH1fh7rOA1\n\t 2brrJji5bUreS9JE/5kgalhWfdmG+k/RdcWSF3JjwisyxUNymlvCJW/T7it+zGwEk6\n\t MOnSbvf95/DGQ==","Date":"Wed, 8 Apr 2026 18:53:16 +0200","From":"Frederic Weisbecker <frederic@kernel.org>","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\t\"Peter Zijlstra (Intel)\" <peterz@infradead.org>,\n\tJohn Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,\n\tAlexander Viro <viro@zeniv.linux.org.uk>,\n\tChristian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n\tlinux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n\tlinux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n\tFlorian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n\tnetfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch V2 01/11] hrtimer: Provide hrtimer_start_range_ns_user()","Message-ID":"<adaH_AVmNLlRd3ep@localhost.localdomain>","References":"<20260408102356.783133335@kernel.org>\n <20260408114951.995031895@kernel.org>","Precedence":"bulk","X-Mailing-List":"netfilter-devel@vger.kernel.org","List-Id":"<netfilter-devel.vger.kernel.org>","List-Subscribe":"<mailto:netfilter-devel+subscribe@vger.kernel.org>","List-Unsubscribe":"<mailto:netfilter-devel+unsubscribe@vger.kernel.org>","MIME-Version":"1.0","Content-Type":"text/plain; charset=iso-8859-1","Content-Disposition":"inline","Content-Transfer-Encoding":"8bit","In-Reply-To":"<20260408114951.995031895@kernel.org>"}}]