[{"id":3674033,"web_url":"http://patchwork.ozlabs.org/comment/3674033/","msgid":"<20260407094206.GL2872@noisy.programming.kicks-ass.net>","list_archive_url":null,"date":"2026-04-07T09:42:06","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":493,"url":"http://patchwork.ozlabs.org/api/people/493/","name":"Peter Zijlstra","email":"peterz@infradead.org"},"content":"On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n\n\n> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo\n>  \t\treturn dev->set_next_ktime(expires, dev);\n>  \n>  \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n> -\tif (delta <= 0)\n> -\t\treturn force ? clockevents_program_min_delta(dev) : -ETIME;\n>  \n> -\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n> -\tdelta = max(delta, (int64_t) dev->min_delta_ns);\n>  \n> -\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> -\trc = dev->set_next_event((unsigned long) clc, dev);\n>  \n> -\treturn (rc && force) ? clockevents_program_min_delta(dev) : rc;\n>  }\n\n> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo\n>  \t\treturn dev->set_next_ktime(expires, dev);\n>  \n>  \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n>  \n> +\tif (delta > (int64_t)dev->min_delta_ns) {\n> +\t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n> +\t\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> +\t\tif (!dev->set_next_event((unsigned long) clc, dev))\n> +\t\t\treturn 0;\n> +\t}\n>  \n> +\tif (dev->next_event_forced)\n> +\t\treturn 0;\n>  \n> +\tif (dev->set_next_event(dev->min_delta_ticks, dev)) {\n> +\t\tif (!force || clockevents_program_min_delta(dev))\n> +\t\t\treturn -ETIME;\n> +\t}\n> +\tdev->next_event_forced = 1;\n> +\treturn 0;\n>  }\n\nLooking at the implementation of clockevents_program_min_delta() doing\nthat dev->set_next_event(dev->min_delta_ticks,) right before it seems a\nbit daft.\n\nBut yes, this is effectively also what the old code did.\n\nThe only thing that seems to be different, is that the old code would\nreturn the ->set_next_event() error code, rather than 0 in the !force\ncase.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11655-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 secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=casper.20170209 header.b=GL3fX06D;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11655-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=\"GL3fX06D\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=90.155.50.34","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=infradead.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqhCz6xDJz1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 07 Apr 2026 19:46:23 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id CE1A9302AC03\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 09:42:21 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 24F953A6B96;\n\tTue,  7 Apr 2026 09:42:20 +0000 (UTC)","from casper.infradead.org (casper.infradead.org [90.155.50.34])\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 BADB226ED45;\n\tTue,  7 Apr 2026 09:42:17 +0000 (UTC)","from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252]\n helo=noisy.programming.kicks-ass.net)\n\tby casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wA2wh-00000003LSG-2XYi;\n\tTue, 07 Apr 2026 09:42:07 +0000","by noisy.programming.kicks-ass.net (Postfix, from userid 1000)\n\tid 3821730035C; Tue, 07 Apr 2026 11:42:06 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775554939; cv=none;\n b=Gt6D+JjAqnjqdO/iOo2rmgvqdCNENWLBxnYdb8S1DLXn6cem5dM/zlvSwBNd6NJ8IPMjpgaG5CXOC2pjLoSnuDbqbHvkPGImw5rx+u9kkmil/cmB7uD0ux6N8rm25+hqo2PTLG61LmKZAV8YkpONoY4o4GTppa4xCYHcEhtnUuQ=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775554939; c=relaxed/simple;\n\tbh=TAAVNXJt51bsnk1asDblEQR6M53ygAwyLlFgg2d2NI4=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=jXk2v7tg3EGST2c/GFI3pazJOF24qX4dTjRAri1nfc1qDgr3JgpzFbVaLcraz+IZRwM84WfMpTmfxMwH6DV8K514rOxTrR/9atjGfqIdxum00ZtA3mpM2IqAtpRrfHaCM1iXbK7iXGhYbVRitAVabJ3dKko+Q6Enc5oTSSte5U0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n spf=none smtp.mailfrom=infradead.org;\n dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=GL3fX06D; arc=none smtp.client-ip=90.155.50.34","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=jtdKMQ8pJX5L5Lx4J8z/WcoGP9UCW0UUWoW6S6I0dcg=; b=GL3fX06DnxaApfB2NuKQVa8Jcx\n\tdPUkc+Md8AanQXzfLXAQ53elA+FIaav91uAiWNdqdEz4ZTRm2sb7rhWM1tUCcQqMVyUWgdt1+5H39\n\tO86QS2n2KbzJIoTC70euaDqplpYU8TB0piauT/PRjQpkeU144lk4o0cf57LqTJU5hkQBuHFeP7OMf\n\tEUxsGgvrej6riIHzP2YtwTskl/Ob9s0myC9YXgZBE3hWB445AtJd/J+9ITckmU/qUWFBjE0I8Nkjm\n\t1LX+tYhk6wTc0wRbJ5RQYtnyrsEfvzi91jBO7IXZl9GoTKXb0tMdDGIDeryKGCUx1GxizWypbT7FR\n\tNh8B/WYA==;","Date":"Tue, 7 Apr 2026 11:42:06 +0200","From":"Peter Zijlstra <peterz@infradead.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\tFrederic Weisbecker <frederic@kernel.org>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<20260407094206.GL2872@noisy.programming.kicks-ass.net>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@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=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260407083247.562657657@kernel.org>"}},{"id":3674105,"web_url":"http://patchwork.ozlabs.org/comment/3674105/","msgid":"<87o6jv57od.ffs@tglx>","list_archive_url":null,"date":"2026-04-07T11:30:42","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Tue, Apr 07 2026 at 11:42, Peter Zijlstra wrote:\n> On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n>> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo\n>>  \t\treturn dev->set_next_ktime(expires, dev);\n>>  \n>>  \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n>>  \n>> +\tif (delta > (int64_t)dev->min_delta_ns) {\n>> +\t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n>> +\t\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n>> +\t\tif (!dev->set_next_event((unsigned long) clc, dev))\n>> +\t\t\treturn 0;\n>> +\t}\n>>  \n>> +\tif (dev->next_event_forced)\n>> +\t\treturn 0;\n>>  \n>> +\tif (dev->set_next_event(dev->min_delta_ticks, dev)) {\n>> +\t\tif (!force || clockevents_program_min_delta(dev))\n>> +\t\t\treturn -ETIME;\n>> +\t}\n>> +\tdev->next_event_forced = 1;\n>> +\treturn 0;\n>>  }\n>\n> Looking at the implementation of clockevents_program_min_delta() doing\n> that dev->set_next_event(dev->min_delta_ticks,) right before it seems a\n> bit daft.\n>\n> But yes, this is effectively also what the old code did.\n\nyes. I looked at that and didn't come up with a good plan.\n\n> The only thing that seems to be different, is that the old code would\n> return the ->set_next_event() error code, rather than 0 in the !force\n> case.\n\nYou mean when dev->next_event_forced is set and the set_event() callback\nabove failed?\n\nThanks,\n\n        tglx","headers":{"Return-Path":"\n <netfilter-devel+bounces-11666-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=pu1umOkZ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11666-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=\"pu1umOkZ\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqkYM69R8z1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 07 Apr 2026 21:31:35 +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 0052A3029605\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 11:30:48 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DE4E93AE6E8;\n\tTue,  7 Apr 2026 11:30:46 +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 64A21331215;\n\tTue,  7 Apr 2026 11:30:46 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 32E2AC19421;\n\tTue,  7 Apr 2026 11:30:44 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775561446; cv=none;\n b=Ov46tzhAm+YWDesyD1pjw2QNEShLPDQvGCcyqlf7zIwbmoCtSHoYMO/dGH1yOrntOXlMvOY//AexmxjMhOUB88O5136wFM+Rn6GMfOb1WTmz8PKeStPeCAcyZQHlFMULeOAlBRHJBUQhXB+UU/C6AVYqABd3IEH3SuXWwO4a3r0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775561446; c=relaxed/simple;\n\tbh=6BhrKoeoCszgRC/OODlv5pmb3yGXumLFVq2zS+cwJuA=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=KDuDM2o88c8ErzzP5shDieoDlrXbSaHsbE9TVdoZy+rwbAZL9ByRskN03UuZ4mt9YKd2LeA+W9uY25K1z72CJ5+uCzYQRCy3F7EmUlzsa0VQJ9qa874Mgc+FqdjrlulRhzyHjM2IiRtXeshHsE/p08bDw4/g/vwbuFdgzCovA7Q=","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=pu1umOkZ; 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=1775561446;\n\tbh=6BhrKoeoCszgRC/OODlv5pmb3yGXumLFVq2zS+cwJuA=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=pu1umOkZ0u5gBSIXckgOLS/jcNaO9PbaoX3hg0T687IsqJ1ftpl8ffesbVVAoTLD0\n\t DUJuYgHbG6ylBu7LtnghFJCjFz9DZr945R4b3VZgQW9/IN2OO7VrYqAOVJUHj2eIB/\n\t vvN+O0e0kGOvdni3IK1O/2UZkSjt07P5jyengoEZ1Yjpzgpzn6E7T7f+9Ywjcrv/TJ\n\t FbTMmYeXFQEC8/b19o61InykP2ov2eMeF7nD13wnFT9mfN6Q5AvGk+AhU86kN7gEUZ\n\t EeppeLzuxp517ay6Mr3ECCuA00DQr3annnMnyR0wNRArd45qacOh5t60fkBoDNZ1qt\n\t +8+VG49bFNgNQ==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Peter Zijlstra <peterz@infradead.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Frederic Weisbecker\n <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>, John Stultz\n <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, Alexander Viro\n <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan\n Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, Sebastian Reichel\n <sre@kernel.org>, linux-pm@vger.kernel.org, Pablo Neira Ayuso\n <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>, Phil Sutter\n <phil@nwl.cc>, netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<20260407094206.GL2872@noisy.programming.kicks-ass.net>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260407094206.GL2872@noisy.programming.kicks-ass.net>","Date":"Tue, 07 Apr 2026 13:30:42 +0200","Message-ID":"<87o6jv57od.ffs@tglx>","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"}},{"id":3674119,"web_url":"http://patchwork.ozlabs.org/comment/3674119/","msgid":"<20260407114905.GH3738786@noisy.programming.kicks-ass.net>","list_archive_url":null,"date":"2026-04-07T11:49:05","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":493,"url":"http://patchwork.ozlabs.org/api/people/493/","name":"Peter Zijlstra","email":"peterz@infradead.org"},"content":"On Tue, Apr 07, 2026 at 01:30:42PM +0200, Thomas Gleixner wrote:\n> On Tue, Apr 07 2026 at 11:42, Peter Zijlstra wrote:\n> > On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n> >> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo\n> >>  \t\treturn dev->set_next_ktime(expires, dev);\n> >>  \n> >>  \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n> >>  \n> >> +\tif (delta > (int64_t)dev->min_delta_ns) {\n> >> +\t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n> >> +\t\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> >> +\t\tif (!dev->set_next_event((unsigned long) clc, dev))\n> >> +\t\t\treturn 0;\n> >> +\t}\n> >>  \n> >> +\tif (dev->next_event_forced)\n> >> +\t\treturn 0;\n> >>  \n> >> +\tif (dev->set_next_event(dev->min_delta_ticks, dev)) {\n> >> +\t\tif (!force || clockevents_program_min_delta(dev))\n> >> +\t\t\treturn -ETIME;\n> >> +\t}\n> >> +\tdev->next_event_forced = 1;\n> >> +\treturn 0;\n> >>  }\n> >\n> > Looking at the implementation of clockevents_program_min_delta() doing\n> > that dev->set_next_event(dev->min_delta_ticks,) right before it seems a\n> > bit daft.\n> >\n> > But yes, this is effectively also what the old code did.\n> \n> yes. I looked at that and didn't come up with a good plan.\n> \n> > The only thing that seems to be different, is that the old code would\n> > return the ->set_next_event() error code, rather than 0 in the !force\n> > case.\n> \n> You mean when dev->next_event_forced is set and the set_event() callback\n> above failed?\n\nnext_event_foced = 0;\nforce = 0;\n\nThen the old code would return rc (return value of ->set_next_event),\nwhile the new code will return -ETIME.\n\n(not 0 like I said).\n\nI suppose ->set_next_event() will only ever fail with -ETIME?","headers":{"Return-Path":"\n <netfilter-devel+bounces-11672-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 secure) header.d=infradead.org header.i=@infradead.org header.a=rsa-sha256\n header.s=desiato.20200630 header.b=D5WWuZ/n;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11672-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=\"D5WWuZ/n\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=90.155.92.199","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org","smtp.subspace.kernel.org;\n spf=none smtp.mailfrom=infradead.org"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqkyT0RDBz1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 07 Apr 2026 21:49:53 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 42EC43034B1B\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 11:49:23 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 4435D3A4F3D;\n\tTue,  7 Apr 2026 11:49:17 +0000 (UTC)","from desiato.infradead.org (desiato.infradead.org [90.155.92.199])\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 6535C303A37;\n\tTue,  7 Apr 2026 11:49:10 +0000 (UTC)","from\n 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl\n ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc]\n helo=noisy.programming.kicks-ass.net)\n\tby desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))\n\tid 1wA4va-00000008AsO-3bg3;\n\tTue, 07 Apr 2026 11:49:06 +0000","by noisy.programming.kicks-ass.net (Postfix, from userid 1000)\n\tid D48A63005E5; Tue, 07 Apr 2026 13:49:05 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775562555; cv=none;\n b=loheEGCmDFUDb1jhJ2sC6EmqfoZ9aD54qWAu6L4lhV2gtScmwspKtf47LDhs0zZ+Oh1PR+/CUAR+PCwlg3C4/1F19bGtVIkbjDY3Gpf9n875hI+G4vqwaNun5IQWkUwpkgCXqwK5UXVGynU0lgje5U6IqAMDoxbxldLV0VdNOFs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775562555; c=relaxed/simple;\n\tbh=MO9im/xFLEozcyFMqpvs9dswnDFDbnWFniJcvlkhh24=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=JApeR5ZGTRczuAIRayoCBciR0T65+T5dNjvIK98ymSQ7E8SwEAKakGQiVpn1UAHEOeMstXIx6eAUIoYCXysAvTJFx/U29PavmsbJ8LGD2QSz/E5A6fYQDidj6GmgOMvoM3tB9Ti5nylevana6aSp6DErYFu0d/f0EOflrW1id9Q=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=infradead.org;\n spf=none smtp.mailfrom=infradead.org;\n dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org\n header.b=D5WWuZ/n; arc=none smtp.client-ip=90.155.92.199","DKIM-Signature":"v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;\n\td=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version:\n\tReferences:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:\n\tContent-Transfer-Encoding:Content-ID:Content-Description;\n\tbh=AOiov/rJ08Wqv5Fg1zDIZQIesob5WeDWCeODzqso7UU=; b=D5WWuZ/nlqC5dXoZA7LA0EqEBZ\n\tOHmSa3QmVSMwpsw4Xzh6SD0HSTXUd5XvG4T7RD3ZuWN/0VRudfvxaoASr7EJfaAQoeZbs660dhgG2\n\tPMwi2C5BlRpZIk+5totSG8YpwHaCGrFaJ2cUKqZGcNCeVr5MpKaJyL0nZusX7Zn6Om6O/PKYU8oVm\n\t/ClWQ0naH4ibGkXpwizELgMjsR2UMkrZOAJLc0us4xrVwBAtD+g6VwHeQbzJkILez1nGzow8fh4co\n\t+a+vj3zrl3z6keKFjEOGlmA0IZMYZnsni2XV3v79SxJ6CIHvb5nHDe7DWHJvN8JSOrK43YACy4ZHI\n\ttgLHgkig==;","Date":"Tue, 7 Apr 2026 13:49:05 +0200","From":"Peter Zijlstra <peterz@infradead.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\tFrederic Weisbecker <frederic@kernel.org>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<20260407114905.GH3738786@noisy.programming.kicks-ass.net>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260407094206.GL2872@noisy.programming.kicks-ass.net>\n <87o6jv57od.ffs@tglx>","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=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87o6jv57od.ffs@tglx>"}},{"id":3674198,"web_url":"http://patchwork.ozlabs.org/comment/3674198/","msgid":"<874ilm6fcq.ffs@tglx>","list_archive_url":null,"date":"2026-04-07T13:59:33","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Tue, Apr 07 2026 at 13:49, Peter Zijlstra wrote:\n> On Tue, Apr 07, 2026 at 01:30:42PM +0200, Thomas Gleixner wrote:\n>> > The only thing that seems to be different, is that the old code would\n>> > return the ->set_next_event() error code, rather than 0 in the !force\n>> > case.\n>> \n>> You mean when dev->next_event_forced is set and the set_event() callback\n>> above failed?\n>\n> next_event_foced = 0;\n> force = 0;\n>\n> Then the old code would return rc (return value of ->set_next_event),\n> while the new code will return -ETIME.\n>\n> (not 0 like I said).\n\nAh. Now it makes sense :)\n\n> I suppose ->set_next_event() will only ever fail with -ETIME?\n\nYes.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11674-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=WQxfPSXu;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11674-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=\"WQxfPSXu\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::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 4fqnrL2f8Lz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 07 Apr 2026 23:59:46 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 88032300E28D\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 13:59:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 19C443B8D6A;\n\tTue,  7 Apr 2026 13:59:38 +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 7CB843B636E;\n\tTue,  7 Apr 2026 13:59:37 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 3EF0BC116C6;\n\tTue,  7 Apr 2026 13:59:35 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775570377; cv=none;\n b=DRJRe+bHYkvVsy+aMHjisYhpp8Pf2U3j1mmMRJMpbmWE2B+n0oj0h0TLZKw8xHIIyaK+MCAGWv4BRmT5T0LIkWgHqa71hfD1I0Zu0Y8mssEJ/NF4FvLegsBa/pNNYcSMSdP1jNwdy8LDg1p+gLYKnmcYkhpUWPezpHkg72+OoRg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775570377; c=relaxed/simple;\n\tbh=unwgo3pndGLEs3AMBmaplmpaq1/djqniJwe60B3hWng=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=WWoqzLq8nvh/FO7y7e0WTv4mgsEcA0SSEEB17U3h5OPqQjYOsg87zTa6vo4GdPlRo9D5+YFPXLEUp3YBPGaK24tDWVeCEHYJH89JYP2X3eTSbql/BpSReLjWeXaOOJlX/CHoUxN0JKrv9leS97B4QFJNfew3sNzdE/WhVV4jYSc=","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=WQxfPSXu; 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=1775570377;\n\tbh=unwgo3pndGLEs3AMBmaplmpaq1/djqniJwe60B3hWng=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=WQxfPSXuMCd6xSvlhDRO6e+7fMGGLN/ThRI7h//PPrWpcfG8ZSXUgIjZhI0egEv+p\n\t MjrTo9CiYI7Ciqv1uJ13bb2p5t59RLMmnbejRC2vpqFGU5xz65BrZ4BAPZHAcFV9Bc\n\t L4XvgMQ6+licrdpXNtzIYybyKDHc+ZsI88lYDQZHMMMQCUi1rwOGCPdTue5jLCnJZT\n\t YJ86PbLo/n7S7p30jWRgpc2So9oPYEjovdxMdtktg+JCf8z5D4pz0ag5oTXbPV80FS\n\t rSEPffFevkOSo8VzzSNscUOgPyI8QZs4qel4/AVDp9O4XRWNLDKYapV7zLtnHEj5vE\n\t DKmV+29DbQxJw==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Peter Zijlstra <peterz@infradead.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Frederic Weisbecker\n <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>, John Stultz\n <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, Alexander Viro\n <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan\n Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, Sebastian Reichel\n <sre@kernel.org>, linux-pm@vger.kernel.org, Pablo Neira Ayuso\n <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>, Phil Sutter\n <phil@nwl.cc>, netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<20260407114905.GH3738786@noisy.programming.kicks-ass.net>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260407094206.GL2872@noisy.programming.kicks-ass.net>\n <87o6jv57od.ffs@tglx>\n <20260407114905.GH3738786@noisy.programming.kicks-ass.net>","Date":"Tue, 07 Apr 2026 15:59:33 +0200","Message-ID":"<874ilm6fcq.ffs@tglx>","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"}},{"id":3674199,"web_url":"http://patchwork.ozlabs.org/comment/3674199/","msgid":"<adUN5Y9-1kx5FVHd@localhost.localdomain>","list_archive_url":null,"date":"2026-04-07T14:00:05","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":79411,"url":"http://patchwork.ozlabs.org/api/people/79411/","name":"Frederic Weisbecker","email":"frederic@kernel.org"},"content":"Le Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner a écrit :\n> From: Thomas Gleixner <tglx@kernel.org>\n> \n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>      - a forced minimum delta event is pending\n>      - the new expiry delta is less then or equal to the minimum delta\n> \n> Thanks to Calvin for providing the reproducer and to Borislav for testing\n> and providing data from his Zen5 machine.\n> \n> The problem is not limited to Zen5, but depending on the underlying\n> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n> not necessarily observable.\n> \n> This change serves only as the last resort and further changes will be made\n> to prevent this scenario earlier in the call chain as far as possible.\n> \n> Fixes: d316c57ff6bf (\"[PATCH] clockevents: add core functionality\")\n> Reported-by: Calvin Owens <calvin@wbinvd.org>\n> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n> Cc: Peter Zijlstra <peterz@infradead.org>\n> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n> Cc: Frederic Weisbecker <frederic@kernel.org>\n> Cc: Ingo Molnar <mingo@kernel.org>\n> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n> ---\n> V2: Simplified the clockevents code - Peter\n\nIsn't it possible to rely on dev->next_event instead? In the above scenario,\nsubsequent 0 delta would not reprogram if dev->next_event is already below\nthe new call to ktime_get() ?\n\nThanks.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11675-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=pq6cE2vr;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11675-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=\"pq6cE2vr\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::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 4fqnsp2YB2z1xy1\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 00:01:02 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id BFE0D3010605\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 14:00:24 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E53FC3B9D98;\n\tTue,  7 Apr 2026 14:00:08 +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 6DC383B8934;\n\tTue,  7 Apr 2026 14:00:08 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id BAE54C4AF0B;\n\tTue,  7 Apr 2026 14:00:07 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775570408; cv=none;\n b=no7Y+78q7IyfmSBDSAR76v2eZdHr0UPxIOpzEJzC2W19spCgDpuZ0OB9HU5S8+bRYhWVc4LKvXFGIb/1fLKgUgnzHd8wr3nEEqmDYB3pAU81vR+Vz2qp3wid9LQqmoIQxcplbC9iaZCqF1MAm0kzrio2EsjsGRQnJQel8yX60CU=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775570408; c=relaxed/simple;\n\tbh=R3FPgUBIyXd8toX27lC987LhlBPlcjngidTNB968ukE=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=lNy97JZSWijwL7eTz1UEE7TxUKJXTPFrVAd43Qzj7uO9BbNXHGdJgLxKemBBKK1Xu0Imc4blLsrb+SBZJPbS9NJmArKabS24cy7zSyK3E6IjxWdJoOBwoSeYNlBGi6aX0XJFwGg5y4W3QWrtBiDKyImAMvGAWCbHO1p1yh3eWj8=","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=pq6cE2vr; 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=1775570408;\n\tbh=R3FPgUBIyXd8toX27lC987LhlBPlcjngidTNB968ukE=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=pq6cE2vrKQZVnXXOiLpQL4qQvqmd0t+4rQFuqwO2IdzMK9GyGbNUnZFL0pOGWkVT9\n\t Ui/8NTG1IZsJ+hVF08dqQAwGZP+ymY9CZySkCDFKVgQRgNodoWVUBaPPTHS885UJ5W\n\t V7QtdOk133p2fCFZZnslBSF9NxkNio22U5EjuyAicxG0IjFw21VYhUs0S8lm5roDak\n\t NXkiKRSfmTPETsDQ7Yj1g8T/z6YO+fjFF7FmLP1TN2uZbnwSZXeeAEQ0ce62XoxW6g\n\t 5eA5jKZLoORFdDoaN21mLjrrzefSvy4cLOEeZtPDYdh+UWktRGJyulgE9KN4333u1A\n\t dSJZXJpXrUH7A==","Date":"Tue, 7 Apr 2026 16:00:05 +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\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<adUN5Y9-1kx5FVHd@localhost.localdomain>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@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":"<20260407083247.562657657@kernel.org>"}},{"id":3674219,"web_url":"http://patchwork.ozlabs.org/comment/3674219/","msgid":"<87zf3e4z79.ffs@tglx>","list_archive_url":null,"date":"2026-04-07T14:33:46","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"Calvin!\n\nOn Tue, Apr 07 2026 at 10:54, Thomas Gleixner wrote:\n> From: Thomas Gleixner <tglx@kernel.org>\n>\n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>      - a forced minimum delta event is pending\n>      - the new expiry delta is less then or equal to the minimum delta\n>\n> Thanks to Calvin for providing the reproducer and to Borislav for testing\n> and providing data from his Zen5 machine.\n>\n> The problem is not limited to Zen5, but depending on the underlying\n> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n> not necessarily observable.\n>\n> This change serves only as the last resort and further changes will be made\n> to prevent this scenario earlier in the call chain as far as possible.\n\nIt'd be great if you could re-test this one independently of the other\nchanges, so we can get that on the way ASAP.\n\nThanks,\n\n        tglx","headers":{"Return-Path":"\n <netfilter-devel+bounces-11690-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=F77WaqmB;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11690-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=\"F77WaqmB\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqpkv2cLsz1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 00:40:07 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 8E3E5319D46A\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 14:34:05 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 12B6926FA5B;\n\tTue,  7 Apr 2026 14:33:51 +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 8F64A22083;\n\tTue,  7 Apr 2026 14:33:50 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 5EBAFC116C6;\n\tTue,  7 Apr 2026 14:33:49 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775572430; cv=none;\n b=LJleGqVeVhTAhUwxv1VWRYOOP+D2smD8RXxpKr0OuqIAtvLCKaEa0tF3xuZ0OhgyIwcuUdfiYDd7PTCjlmd4zJIZGeRtIUg1TYhdYd2WMtBI+SR/w33LXHB4X3Z2Z+Dg07pac3oZBm+zMtKv0F90Rr3glf4Af3ZIRUzfN7jKAcQ=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775572430; c=relaxed/simple;\n\tbh=c1UWCjgwFCzeY3oC22UZNQKZhUQeoeGwKeI7oZChdzk=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=KWXVQtUlqd636ikoVtUceE2F85E6QCR41D72JcvXszrorS/ayx/wTav7ip3WFPUNj6nd9HE5xYlCptHbe4QkcZYZB+gMuQhRehpmF6Rg58ANTMBhCok02lmYxje6dGTORZvLHV7n8SNHU5mrvpfs+7sVBfIkKCCdEX6VtWE6M9I=","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=F77WaqmB; 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=1775572430;\n\tbh=c1UWCjgwFCzeY3oC22UZNQKZhUQeoeGwKeI7oZChdzk=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=F77WaqmBAH9iU0nJ2xb+VzdV0jLmo7aypOBP3uqgytPiv5roeC2nq8DxgSQDZFEs0\n\t +/NL5Ux6Rti5wwKEtQDn4xxDGREld11yHoLVEn9UUzUxhISAbl4a5FKNaPV0YRY8qK\n\t fnUKaU2Rrc097AcglXWNjYHaE3WgrfJUHVhchJSbl7VwU7/2q+xnFDUFhoby9bG97F\n\t cQODvHx/iap8crqKFc3+AAQML/3Vpt2wLv8bEVVIh+aAfdClY58h15NB3G6BrLiQyU\n\t +BR2d9yRvsX0uavWrkm+LaZrtWw+sJwQkSoeHAH2cbMTqbFxLQUxyBI92JAMDP4sXz\n\t CFIaJFbHBQgCQ==","From":"Thomas Gleixner <tglx@kernel.org>","To":"LKML <linux-kernel@vger.kernel.org>","Cc":"Calvin Owens <calvin@wbinvd.org>, Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Frederic Weisbecker\n <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>, John Stultz\n <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, Alexander Viro\n <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan\n Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, Sebastian Reichel\n <sre@kernel.org>, linux-pm@vger.kernel.org, Pablo Neira Ayuso\n <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>, Phil Sutter\n <phil@nwl.cc>, netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<20260407083247.562657657@kernel.org>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>","Date":"Tue, 07 Apr 2026 16:33:46 +0200","Message-ID":"<87zf3e4z79.ffs@tglx>","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"}},{"id":3674284,"web_url":"http://patchwork.ozlabs.org/comment/3674284/","msgid":"<87tstm4uss.ffs@tglx>","list_archive_url":null,"date":"2026-04-07T16:08:51","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Tue, Apr 07 2026 at 16:00, Frederic Weisbecker wrote:\n> Le Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner a écrit :\n>> From: Thomas Gleixner <tglx@kernel.org>\n>> \n>> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n>> up in user space. He provided a reproducer, which sets 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>> As a first step to prevent this, avoid reprogramming the clock event device\n>> when:\n>>      - a forced minimum delta event is pending\n>>      - the new expiry delta is less then or equal to the minimum delta\n>> \n>> Thanks to Calvin for providing the reproducer and to Borislav for testing\n>> and providing data from his Zen5 machine.\n>> \n>> The problem is not limited to Zen5, but depending on the underlying\n>> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n>> not necessarily observable.\n>> \n>> This change serves only as the last resort and further changes will be made\n>> to prevent this scenario earlier in the call chain as far as possible.\n>> \n>> Fixes: d316c57ff6bf (\"[PATCH] clockevents: add core functionality\")\n>> Reported-by: Calvin Owens <calvin@wbinvd.org>\n>> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n>> Cc: Peter Zijlstra <peterz@infradead.org>\n>> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n>> Cc: Frederic Weisbecker <frederic@kernel.org>\n>> Cc: Ingo Molnar <mingo@kernel.org>\n>> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n>> ---\n>> V2: Simplified the clockevents code - Peter\n>\n> Isn't it possible to rely on dev->next_event instead? In the above scenario,\n> subsequent 0 delta would not reprogram if dev->next_event is already below\n> the new call to ktime_get() ?\n\nIt does if force is set and that is set when hrtimer calls into it:\n\n\tif (delta <= 0)\n\t\treturn force ? clockevents_program_min_delta(dev) : -ETIME;\n\nI can't change that for various reasons.\n\nBut we always need the flag which tells us that the programming was\nforced in order to prevent the above scenario. And delta <= 0 is not the\nonly way how to achieve that. You can have a delta > 0 and < min_delta\nanc achieve the same effect. That needs more effort on the callsite, but\nit's trivially doable as the systemcall to reprogram time is pretty\nconstant.\n\nAs I had to introduce the flag and prevent the other scenraio I just\nconsolidated everything into one code path.\n\nThanks,\n\n        tglx","headers":{"Return-Path":"\n <netfilter-devel+bounces-11692-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=jVEf/NAM;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11692-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=\"jVEf/NAM\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fqrtW54Thz1xy1\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 02:16:51 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 7C989305D383\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 16:10:31 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id DF9EC3A5459;\n\tTue,  7 Apr 2026 16:08:58 +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 A8142386452;\n\tTue,  7 Apr 2026 16:08:55 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 62C4BC116C6;\n\tTue,  7 Apr 2026 16:08:54 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775578135; cv=none;\n b=A9iG4YBj3AnKj2iC9MdhsyL/mXC7ydkihTHChFVOOz7/SVyuoo0n06wcXiR1TwxG5PqcediRSQpK5q94NdM3Wz4B6hkZtF8TcVbv8+olsvalVKLPRXJ+I+JruyBSUi2zsB0i9TfixXaQpjUQXwNsUrIBPge44kgRZf6zV3cBhto=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775578135; c=relaxed/simple;\n\tbh=8+XrLn44M7bWBGgQWnF9XOkYXae8VKwXxigNC9f7p5Y=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=uVCQiZ3YOezyuwgQnqxcC/zp4kGGNKVg6vqH1s+86pyQxWu2SQXQ1OqPOzHQtU2a8ISHTDZe9qlCNdfeNi6nFn4pL5fl+Ypx61PqAX2T4kmA/zKZI1O4mnhzuqiW4AU1XkUtKcbsC7DXou6yjxnUJlCT9iy0tTw5cLPO0l+jD50=","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=jVEf/NAM; 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=1775578134;\n\tbh=8+XrLn44M7bWBGgQWnF9XOkYXae8VKwXxigNC9f7p5Y=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=jVEf/NAMTgWPARpL0vC+sFTI8tqsrEnzyPWqT3nNIl6r71v2yGLuhTPICyAKAmc70\n\t E4q4W7aLkI0YZmKrqmIObJahH9pmu13mFJ0CtDdycy5AlxmUVWhLKyBAwENWvDaW0w\n\t xtpcJp5uQFoQ7gEQgdluN3gkROsbSVHEox98nQInI2KL71Abd8+TDm9WaTleYvy0hO\n\t SbTEI7DzzX9uIMf8e6ppiah5IcmMRaAJ35KiJW12GuWoUk/PAT1YPbSREA8bEUUogd\n\t ZVEiMDH0bITT6kvsfppVt94bPQDsSeHEXVGXOX0dHmewM8Sfpom7giRoGPd6VtFzHx\n\t vE0PxN8dXzXWw==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Frederic Weisbecker <frederic@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>, Anna-Maria Behnsen\n <anna-maria@linutronix.de>, Ingo Molnar <mingo@kernel.org>, John Stultz\n <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, Alexander Viro\n <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan\n Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, Sebastian Reichel\n <sre@kernel.org>, linux-pm@vger.kernel.org, Pablo Neira Ayuso\n <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>, Phil Sutter\n <phil@nwl.cc>, netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<adUN5Y9-1kx5FVHd@localhost.localdomain>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <adUN5Y9-1kx5FVHd@localhost.localdomain>","Date":"Tue, 07 Apr 2026 18:08:51 +0200","Message-ID":"<87tstm4uss.ffs@tglx>","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=utf-8","Content-Transfer-Encoding":"quoted-printable"}},{"id":3674324,"web_url":"http://patchwork.ozlabs.org/comment/3674324/","msgid":"<87ldey4pkp.ffs@tglx>","list_archive_url":null,"date":"2026-04-07T18:01:42","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Tue, Apr 07 2026 at 18:08, Thomas Gleixner wrote:\n> On Tue, Apr 07 2026 at 16:00, Frederic Weisbecker wrote:\n> As I had to introduce the flag and prevent the other scenraio I just\n> consolidated everything into one code path.\n\nJust for the record. This whole -ETIME handling is restricted to HPET\nlike devices where the hardware people decided it's a brilliant idea to\nbuild a 'equal' comparator and then followed up by making the write\nposted to reduce the costs of the write. The original direct write was\nalready flawed vs. NMI/SMI, but the delayed commit into the comparator\nmade it insanely broken.\n\nAFAICT that's a handful devices in the zoo of clockevent IPs the kernel\nsupports, so I'm really not too worried about the impact of this change.\nAny sane hardware will never hit that code path so no point for\noptimizing for it.\n\nThanks,\n\n        tglx","headers":{"Return-Path":"\n <netfilter-devel+bounces-11696-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=ffncIQTB;\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-11696-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=\"ffncIQTB\"","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 4fqvDW648Yz1xy1\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 04:02:35 +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 5FDF03058672\n\tfor <incoming@patchwork.ozlabs.org>; Tue,  7 Apr 2026 18:01:48 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 33F783BADA9;\n\tTue,  7 Apr 2026 18:01:47 +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 A200E33F370;\n\tTue,  7 Apr 2026 18:01:46 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 5ECE8C19424;\n\tTue,  7 Apr 2026 18:01:45 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775584906; cv=none;\n b=OPbYWPaCxt9fyXfFHXl2XGV8PhuloBhIwOzvTxW20fFfI6HgMVfTcGg0AzCPw59/WlskBf/sp9EqZ9t/F0XWfJC08FIFw0uBlANoIqYYaOrt0mMjTbp8D+quuztdSlIWxPPYbTEl1wo6M+Y/WDQOgpTPbGNfFNXD7GVadb14ghc=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775584906; c=relaxed/simple;\n\tbh=6B+bB4wDwu6y52UEp2vUDg3kQcT5fRjCxX/e9OhjKYQ=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=fDcrT/Vm+Pnt18Dl0mN+IoeLXXuQDxsfBY9GG5wQn80Sv68ASFpLflbV9ITALug6F7lw9kHpXu9AsDSVXrifP1VfrtuLkB5qySPS8IS8gbbwXiiK2A3cYSbtNB/Nelhpr30E/nqoqMIEAyWUYOeDr/yU9j32RLoKXUIZmTDSSAs=","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=ffncIQTB; 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=1775584906;\n\tbh=6B+bB4wDwu6y52UEp2vUDg3kQcT5fRjCxX/e9OhjKYQ=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=ffncIQTB9uPSPzX+Hl67zcMc6bar4Dmd29wGTqpWwOeGOO4SU1YQ6w0FJYlm5PLeO\n\t fgb/hVw5sv/eL6LG/wa2UmQxRzt2MVjRl+LDbJq4AKYtN45D3Y6b1Xa8dUkSSxkwPZ\n\t 8IIMG/iWcbW7ILFIU/Hy7qbxpuCy61KpvfMjemLmpYNLT4JLCROnyPxgh35IXVE5e0\n\t CrzxrJWUq3nI+ByPHY2xTfuMpKfmLeShgRWSg3reO1A3ddBI6rfxbDA335mYN/KA1g\n\t VEhzOrCmRP6zyYfLam0a05rOF06NG89aw/mchas8rn5jGzUuB/GsJMNazR1DSapjPv\n\t dcpPxlH/SQl+w==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Frederic Weisbecker <frederic@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>, Anna-Maria Behnsen\n <anna-maria@linutronix.de>, Ingo Molnar <mingo@kernel.org>, John Stultz\n <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>, Alexander Viro\n <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>, Jan\n Kara <jack@suse.cz>, linux-fsdevel@vger.kernel.org, Sebastian Reichel\n <sre@kernel.org>, linux-pm@vger.kernel.org, Pablo Neira Ayuso\n <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>, Phil Sutter\n <phil@nwl.cc>, netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<87tstm4uss.ffs@tglx>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <adUN5Y9-1kx5FVHd@localhost.localdomain> <87tstm4uss.ffs@tglx>","Date":"Tue, 07 Apr 2026 20:01:42 +0200","Message-ID":"<87ldey4pkp.ffs@tglx>","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"}},{"id":3674748,"web_url":"http://patchwork.ozlabs.org/comment/3674748/","msgid":"<20260408143313-ac6c3b82-70e6-4ce3-b33a-20f5e6ba160b@linutronix.de>","list_archive_url":null,"date":"2026-04-08T12:41:18","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":87994,"url":"http://patchwork.ozlabs.org/api/people/87994/","name":"Thomas Weißschuh","email":"thomas.weissschuh@linutronix.de"},"content":"Hi Thomas,\n\nOn Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n> From: Thomas Gleixner <tglx@kernel.org>\n> \n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>      - a forced minimum delta event is pending\n>      - the new expiry delta is less then or equal to the minimum delta\n\nwith this patch now in the tip tree my QEMU/virtme-ng based machine\nfails to boot. The startup seems to freeze in:\nstart_kernel() -> rest_init() -> schedule_preempt_disabled() -> schedule()\n\nCONFIG_GENERIC_CLOCKEVENTS=y\nCONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y\nCONFIG_GENERIC_CLOCKEVENTS_BROADCAST_IDLE=y\nCONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y\nCONFIG_HZ=1000\n\nCPU: i5-1135G7\nclock event device: lapic-deadline\n\nThe clockevent device is still reprogrammed each millisecond,\npresumably for the tick.\n\n(...)\n\n\nThomas","headers":{"Return-Path":"\n <netfilter-devel+bounces-11733-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 secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256\n header.s=2020 header.b=1n91fiiJ;\n\tdkim=pass header.d=linutronix.de header.i=@linutronix.de\n header.a=ed25519-sha256 header.s=2020e header.b=g7JLpCYf;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11733-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=\"1n91fiiJ\";\n\tdkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=\"g7JLpCYf\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=193.142.43.55","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linutronix.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linutronix.de"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\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 4frN4B2pbSz1yD3\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 08 Apr 2026 22:42:02 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 9B37A303A8E7\n\tfor <incoming@patchwork.ozlabs.org>; Wed,  8 Apr 2026 12:41:25 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 505D33BD642;\n\tWed,  8 Apr 2026 12:41:24 +0000 (UTC)","from galois.linutronix.de (Galois.linutronix.de [193.142.43.55])\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 967B517A309;\n\tWed,  8 Apr 2026 12:41:22 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775652083; cv=none;\n b=uURpJnWTdostMKvHT8cGbvlbvQoRjxKDfDjwWAZ9PSPrxDzkx3PomRTkmExD9u4jPg7VRsJR1kOvbiXlQ6tjXYO3oMDEtnVMJhoqyXecFMw6smt5W5TSbVdTpsZh9WQpYNICSuuaDZUhWdbrywsBpvCRHsFJEimvNetIvuSY43M=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775652083; c=relaxed/simple;\n\tbh=XXbT5wATVXm4JD/GqE3qctRgdVlK+QcWdXInoVA0dEw=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=F6fTby33+P595p9QCzspHRj+/2c3j4fNCrXOYe30Alf5Y1GSAt6wEYmGZPPvxuFv6kSi/6p0Bu7kZRtayq6EJJzeFhY0WVbg+zVKmoQVYRDldeuHdkn+baZiQTcK8TTpNlgMlpViPCTW18wXoZJW7QzqHnMODm9dPlsllrR3c1s=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linutronix.de;\n spf=pass smtp.mailfrom=linutronix.de;\n dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=1n91fiiJ;\n dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=g7JLpCYf; arc=none smtp.client-ip=193.142.43.55","Date":"Wed, 8 Apr 2026 14:41:18 +0200","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;\n\ts=2020; t=1775652080;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=hjtFJLsP9NFWdv21cGYCI8ngeEXhsnmB0domogAqwu8=;\n\tb=1n91fiiJpKrIK1G6+LKIjYUoFteRmu8RoRSCKHQyX+K8QWongS2ErrP6DsXsqtx+RuWdId\n\tz2R4St5cbfTmc1U+OsVkDrucJJP796PanwJlVtgL7zBZqjZ0/7vgCL1fQMcsHCRVp8PNP7\n\tQBUs7oxAPhlSqzlpamhaWnm7vo0X52YAWTF0Q0ggvAJLAu5F8uGZ4pQmtvp1mewnCpsOAS\n\tQETiwcAXi70/a5puQXgYELHxFVTvmaE8GMuAw0sBqn7FkQ9Fa9vOdbFra4azb1SyBYwybf\n\tSvDcTXxpDdtNiGVnoQpQ/xEAFYVqNzBzwfS40PsjA7HwufoveiqHzZ8RPrRm0Q==","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;\n\ts=2020e; t=1775652080;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=hjtFJLsP9NFWdv21cGYCI8ngeEXhsnmB0domogAqwu8=;\n\tb=g7JLpCYf2VmRPHNYq91fqb0Gi3QAksbyIzlI905BFuId/PaFxj9z7u1L8THQw7Y5ovLP5n\n\trvymZ7LueNwJiODA=="],"From":"Thomas =?utf-8?q?Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>,\n\tFrederic Weisbecker <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>,\n John Stultz <jstultz@google.com>,\n\tStephen Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n\tChristian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org,\n\tSebastian Reichel <sre@kernel.org>, linux-pm@vger.kernel.org,\n\tPablo Neira Ayuso <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>,\n Phil Sutter <phil@nwl.cc>,\n\tnetfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"\n <20260408143313-ac6c3b82-70e6-4ce3-b33a-20f5e6ba160b@linutronix.de>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@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=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260407083247.562657657@kernel.org>"}},{"id":3674789,"web_url":"http://patchwork.ozlabs.org/comment/3674789/","msgid":"<20260408155353-42aeefa4-db66-48aa-ab07-0538a8cfdbf0@linutronix.de>","list_archive_url":null,"date":"2026-04-08T13:55:02","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":87994,"url":"http://patchwork.ozlabs.org/api/people/87994/","name":"Thomas Weißschuh","email":"thomas.weissschuh@linutronix.de"},"content":"On Wed, Apr 08, 2026 at 02:41:20PM +0200, Thomas Weißschuh wrote:\n> Hi Thomas,\n> \n> On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n> > From: Thomas Gleixner <tglx@kernel.org>\n> > \n> > Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> > up in user space. He provided a reproducer, which sets 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> > As a first step to prevent this, avoid reprogramming the clock event device\n> > when:\n> >      - a forced minimum delta event is pending\n> >      - the new expiry delta is less then or equal to the minimum delta\n> \n> with this patch now in the tip tree my QEMU/virtme-ng based machine\n> fails to boot. The startup seems to freeze in:\n> start_kernel() -> rest_init() -> schedule_preempt_disabled() -> schedule()\n> \n> CONFIG_GENERIC_CLOCKEVENTS=y\n> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y\n> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST_IDLE=y\n> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y\n> CONFIG_HZ=1000\n> \n> CPU: i5-1135G7\n> clock event device: lapic-deadline\n> \n> The clockevent device is still reprogrammed each millisecond,\n> presumably for the tick.\n> \n> (...)\n\nThis fixes the issue for me:\n\n--- a/kernel/time/clockevents.c\n+++ b/kernel/time/clockevents.c\n@@ -369,7 +369,7 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b\n        if (dev->next_event_forced)\n                return 0;\n \n-       if (dev->set_next_event(dev->min_delta_ticks, dev)) {\n+       if (dev->set_next_event(dev->min_delta_ns, dev)) {\n                if (!force || clockevents_program_min_delta(dev))\n                        return -ETIME;\n        }\n\n\nThomas","headers":{"Return-Path":"\n <netfilter-devel+bounces-11734-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 secure) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256\n header.s=2020 header.b=g/7igT7Y;\n\tdkim=pass header.d=linutronix.de header.i=@linutronix.de\n header.a=ed25519-sha256 header.s=2020e header.b=bXbgFQGF;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11734-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=\"g/7igT7Y\";\n\tdkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=\"bXbgFQGF\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=193.142.43.55","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linutronix.de","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linutronix.de"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frPpW233nz1xv0\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 09 Apr 2026 00:00:19 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 8A2A6309A0EF\n\tfor <incoming@patchwork.ozlabs.org>; Wed,  8 Apr 2026 13:55:09 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 0226B3D1707;\n\tWed,  8 Apr 2026 13:55:08 +0000 (UTC)","from galois.linutronix.de (Galois.linutronix.de [193.142.43.55])\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 335F6175A5;\n\tWed,  8 Apr 2026 13:55:05 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775656507; cv=none;\n b=S2AeLpEvGa0nNlpnc/FwtlTCxfGnHAdLEp7omuS6gFuMnB1SsX3pp7YdG8rNSY0/Wcd/BEroZKGk2uGEmxW6sLhztxi4jY1TjSrcCrxkOn+NEciJ6RQm90/5vDo8CkQvpA4TIW9Z1deVJgAJ84B8R2mGPPLoSe76nXghJ+Ezdbg=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775656507; c=relaxed/simple;\n\tbh=9V0aEgsGhkLU/YHXT2F9l9I/XcSpUtYjb0B6llutNFo=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Y46Fjrxw5AZ9Hdnr03LyFJwEuDAdhhgw/ETjs+BA5q27soWXNqO/Nh7PWj0vC3n1d1c7VTlY3dPaNKBvzkAXETpqq6zOzzt2SHaeUkl1UFLzqLuFA1QncV1YG1kCFjH8LvRKf2v371jG9Bq10Ho3oF6w/hqNpeQ5buvBcuu2wxs=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linutronix.de;\n spf=pass smtp.mailfrom=linutronix.de;\n dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=g/7igT7Y;\n dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de\n header.b=bXbgFQGF; arc=none smtp.client-ip=193.142.43.55","Date":"Wed, 8 Apr 2026 15:55:02 +0200","DKIM-Signature":["v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;\n\ts=2020; t=1775656503;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=I/7IhEnruGQc+1CW/jI+NpDLfCCCOrjwQ3Z++94aDzE=;\n\tb=g/7igT7YVTjK17e006TVC9a2gKMuvkRBxfOLbKucZK/ors+kGDdqRhg/OqIAPoq5L2zYiR\n\tNHS9iN2kPybQQCMzb0hTPTlJ3hMU1aWfJnzlmiv0KNZqY4Wwi26yUcu/VEQmZb3LrFtLeJ\n\tv9Hj8r5rg9mxwgzJi9+isM2ogGz4hxoBiRV1S6JCNrSj/EZ9vO2oq9kkJwhikSW2SV/nRF\n\tyNWHpa5z8hiS3Hk82KmrT84xlKxjjdnZZkn0SPpkbAL0sSSDZqoPQ1o2o0e5Bm/LDTrW9/\n\tURrBKH+giHCjz0pRM4cLUth3lWFPudMBl7mwDYZfzksl5HySlYmwbAWqBhZ6QQ==","v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;\n\ts=2020e; t=1775656503;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=I/7IhEnruGQc+1CW/jI+NpDLfCCCOrjwQ3Z++94aDzE=;\n\tb=bXbgFQGFM845UyMTzIaKnx+U/0W1qwvKf9VT1aZH2aehpEPkr35D05t97plT1GQ4P43LR/\n\tE8qif45B75rf6LAQ=="],"From":"Thomas =?utf-8?q?Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>,\n\tFrederic Weisbecker <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>,\n John Stultz <jstultz@google.com>,\n\tStephen Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n\tChristian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org,\n\tSebastian Reichel <sre@kernel.org>, linux-pm@vger.kernel.org,\n\tPablo Neira Ayuso <pablo@netfilter.org>, Florian Westphal <fw@strlen.de>,\n Phil Sutter <phil@nwl.cc>,\n\tnetfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"\n <20260408155353-42aeefa4-db66-48aa-ab07-0538a8cfdbf0@linutronix.de>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260408143313-ac6c3b82-70e6-4ce3-b33a-20f5e6ba160b@linutronix.de>","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":"\n <20260408143313-ac6c3b82-70e6-4ce3-b33a-20f5e6ba160b@linutronix.de>"}},{"id":3674796,"web_url":"http://patchwork.ozlabs.org/comment/3674796/","msgid":"<adZi7iFB8hqoaPcu@localhost.localdomain>","list_archive_url":null,"date":"2026-04-08T14:15:10","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":79411,"url":"http://patchwork.ozlabs.org/api/people/79411/","name":"Frederic Weisbecker","email":"frederic@kernel.org"},"content":"Le Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner a écrit :\n> From: Thomas Gleixner <tglx@kernel.org>\n> \n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>      - a forced minimum delta event is pending\n>      - the new expiry delta is less then or equal to the minimum delta\n> \n> Thanks to Calvin for providing the reproducer and to Borislav for testing\n> and providing data from his Zen5 machine.\n> \n> The problem is not limited to Zen5, but depending on the underlying\n> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n> not necessarily observable.\n> \n> This change serves only as the last resort and further changes will be made\n> to prevent this scenario earlier in the call chain as far as possible.\n> \n> Fixes: d316c57ff6bf (\"[PATCH] clockevents: add core functionality\")\n> Reported-by: Calvin Owens <calvin@wbinvd.org>\n> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n> Cc: Peter Zijlstra <peterz@infradead.org>\n> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n> Cc: Frederic Weisbecker <frederic@kernel.org>\n> Cc: Ingo Molnar <mingo@kernel.org>\n> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n\nReviewed-by: Frederic Weisbecker <frederic@kernel.org>","headers":{"Return-Path":"\n <netfilter-devel+bounces-11736-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=S7RMpuEh;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11736-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=\"S7RMpuEh\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::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 4frQ7y62Vmz1xv0\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 09 Apr 2026 00:15:26 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 3D4F83005985\n\tfor <incoming@patchwork.ozlabs.org>; Wed,  8 Apr 2026 14:15:23 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id E03592A1CF;\n\tWed,  8 Apr 2026 14:15:15 +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 EB72C3D333C;\n\tWed,  8 Apr 2026 14:15:13 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id E5A9AC19421;\n\tWed,  8 Apr 2026 14:15:12 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775657714; cv=none;\n b=OJpTODdXaBZDcbBLITSgn9c3zsJDh52+kuaw+XB9SHyxvQT61d7FsxBMSv1xoxqCaU7+c19qwhpgBseISoRXTDMyRFjxi2oi0YsvaoSrtyooOO14Cdr/CE+Y8mmmFCNAzD3279c3K9xwOD4Wi8EXuSJ6pmiDPkGoH04ZDgKp06M=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775657714; c=relaxed/simple;\n\tbh=2GKBWezh0wJ1rxI7mwwrI3CADIBrRX0kcY4kXY4Vgws=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=lHh2BLL5KKEoTgPFzanJTY4RWUYDev0yyGDR3Ie1fkReHT0YBW/PhyWIhkrwiY9WIcSpSLic11UtN3A/QRSoIzQ++UT1OhKEeS5wgN/7u9x49CS0GQbxp157oC+pM/ca0yArrYYvC7RQofUmnYgv1U+jmy9sqke7dWRb9ylKTOo=","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=S7RMpuEh; 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=1775657713;\n\tbh=2GKBWezh0wJ1rxI7mwwrI3CADIBrRX0kcY4kXY4Vgws=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=S7RMpuEhAPW7AoOpjukUkXJY+0IaS3EO36qhsh4pHP7RO2qD8o4j/LAfL2PLYnA9E\n\t ipxgcOMKMjHnufFqMlmIaFmx6ikF9fMJpZSIjwzaA5QqgBONm/RUc6COFkqhGC/aXw\n\t QzVD/keNQftVMS5w6AV3K6rQT2wVra5sdjm5ElRAeT99Jyk5UibxzfyoQ5mDAJTfpL\n\t 8bCNhdEucCP4sh76TdoEf+0DZHkNbt2zoXyZpFbNJ2nVZlprWaE7Ssn7oGmMfkPm6h\n\t QFQXp64lSaUeTm976GITCQtllOBMqK5ELfwfUpBigReRcSwN8/oPD/yPVp7KL5peTw\n\t D0jjt1EBvBonQ==","Date":"Wed, 8 Apr 2026 16:15:10 +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\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<adZi7iFB8hqoaPcu@localhost.localdomain>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@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":"<20260407083247.562657657@kernel.org>"}},{"id":3674830,"web_url":"http://patchwork.ozlabs.org/comment/3674830/","msgid":"<87zf3d32g3.ffs@tglx>","list_archive_url":null,"date":"2026-04-08T15:18:52","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Wed, Apr 08 2026 at 15:55, Thomas Weißschuh wrote:\n> On Wed, Apr 08, 2026 at 02:41:20PM +0200, Thomas Weißschuh wrote:\n> --- a/kernel/time/clockevents.c\n> +++ b/kernel/time/clockevents.c\n> @@ -369,7 +369,7 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b\n>         if (dev->next_event_forced)\n>                 return 0;\n>  \n> -       if (dev->set_next_event(dev->min_delta_ticks, dev)) {\n> +       if (dev->set_next_event(dev->min_delta_ns, dev)) {\n\nThat's wrong as the callback expects cycles (ticks) not nanoseconds.\n\nI've just pushed out an updated version to tip timers/urgent which\naddresses a potentially related issue. Delta patch below.\n\nThanks,\n\n        tglx\n---\n--- a/kernel/time/clockevents.c\n+++ b/kernel/time/clockevents.c\n@@ -324,6 +324,8 @@ int clockevents_program_event(struct clo\n \t\treturn dev->set_next_ktime(expires, dev);\n \n \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n+\tif (delta <= 0 && !force)\n+\t\treturn -ETIME;\n \n \tif (delta > (int64_t)dev->min_delta_ns) {\n \t\tdelta = min(delta, (int64_t) dev->max_delta_ns);","headers":{"Return-Path":"\n <netfilter-devel+bounces-11737-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=VW/ctqfW;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11737-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=\"VW/ctqfW\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4frRct10ZVz1xy1\n\tfor <incoming@patchwork.ozlabs.org>; Thu, 09 Apr 2026 01:22:06 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id EC8143019830\n\tfor <incoming@patchwork.ozlabs.org>; Wed,  8 Apr 2026 15:19:01 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2896F3D646D;\n\tWed,  8 Apr 2026 15:18:59 +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 A10AF33CEA8;\n\tWed,  8 Apr 2026 15:18:56 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 43AAAC19421;\n\tWed,  8 Apr 2026 15:18:54 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775661536; cv=none;\n b=YIDqanZrVvQ9lKC7T1+Fas+O/MvGd14zjpMkvCCX0e7LSje0UIY9zk6pPb6REhPuEjviKz+KX2m3ZET0m/pdbcK2P0Azujz+la2j3mqj0hR0s+JpyrnoNr7RNg9uxp19g60hUEltBLkL234oT9U6+tkxHga3jJHVAwivD0Abadk=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775661536; c=relaxed/simple;\n\tbh=K0smtATRRlPhzZC/f2FuIGBbZSELomfitHg/FX7/F+c=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=iEO/y9+6ejXZVaGCFO8haC0YEsA72V0c4lpaJJlMixkC2GaNgYG0N4sZ5wMzjKjUqqgX9gaZ8xGBeCvVEiu18ACdbDwM9LI0qYC6vpqUu/pp2MdvvSOw+zg9c0ERRt8/VitzKZfBugCoz6pN6kRiuK9r4J1v326pYY457tTYw4c=","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=VW/ctqfW; 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=1775661536;\n\tbh=K0smtATRRlPhzZC/f2FuIGBbZSELomfitHg/FX7/F+c=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=VW/ctqfWbUrk670cLw5GbIb5IloiAdZviNrvkFPmmqRL6p6+EHv5DTHowzQ3ovPHw\n\t aRyqchU1bT7LNV6SxiCzsNRrDzSIksRADxnKGdFnxZu5htqCFFWMc5u4QUutAHEU1e\n\t bbeMUvdRBC/OUqesuEbPWcgFzb7v3IPc6PFqJ5FWwDz5RC8ZiqmsiYY+EOitBJtd7e\n\t +CqsG0M1uIUi6yhv0paoxwNL2WB4EdiwtIPK93Jo3LVqSamcT+azpoKYqcMOBSsiMo\n\t dcSjPFgJA5WWka/2nOwZ8pzHBEmYJXn6Y5bhs6DwVHhWS5jUB27L4TVtnPgc+wdJD+\n\t nz239NiXc2oxw==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Thomas =?utf-8?q?Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>, Anna-Maria Behnsen\n <anna-maria@linutronix.de>, Frederic Weisbecker <frederic@kernel.org>,\n Ingo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>, Stephen\n Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>, Florian\n Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"\n <20260408155353-42aeefa4-db66-48aa-ab07-0538a8cfdbf0@linutronix.de>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260408143313-ac6c3b82-70e6-4ce3-b33a-20f5e6ba160b@linutronix.de>\n <20260408155353-42aeefa4-db66-48aa-ab07-0538a8cfdbf0@linutronix.de>","Date":"Wed, 08 Apr 2026 17:18:52 +0200","Message-ID":"<87zf3d32g3.ffs@tglx>","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=utf-8","Content-Transfer-Encoding":"quoted-printable"}},{"id":3676046,"web_url":"http://patchwork.ozlabs.org/comment/3676046/","msgid":"<20260410205203.GA3922321@ax162>","list_archive_url":null,"date":"2026-04-10T20:52:03","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":81040,"url":"http://patchwork.ozlabs.org/api/people/81040/","name":"Nathan Chancellor","email":"nathan@kernel.org"},"content":"Hi Thomas,\n\nOn Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:\n> From: Thomas Gleixner <tglx@kernel.org>\n> \n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>      - a forced minimum delta event is pending\n>      - the new expiry delta is less then or equal to the minimum delta\n> \n> Thanks to Calvin for providing the reproducer and to Borislav for testing\n> and providing data from his Zen5 machine.\n> \n> The problem is not limited to Zen5, but depending on the underlying\n> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n> not necessarily observable.\n> \n> This change serves only as the last resort and further changes will be made\n> to prevent this scenario earlier in the call chain as far as possible.\n> \n> Fixes: d316c57ff6bf (\"[PATCH] clockevents: add core functionality\")\n> Reported-by: Calvin Owens <calvin@wbinvd.org>\n> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n> Cc: Peter Zijlstra <peterz@infradead.org>\n> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n> Cc: Frederic Weisbecker <frederic@kernel.org>\n> Cc: Ingo Molnar <mingo@kernel.org>\n> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n\nThis change in -next as commit 1c2eabb8805d (\"clockevents: Prevent timer\ninterrupt starvation\") appears to make one of my test machines\nconsistently lock up on boot (at least I never get to userspace). Most\nof the time I get stall messages such as\n\n  rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n  rcu:    14-...!: (20 GPs behind) idle=f380/0/0x0 softirq=1272/1273 fqs=4 (false positive?)\n  rcu:    (detected by 2, t=60002 jiffies, g=3673, q=12382 ncpus=16)\n  Sending NMI from CPU 2 to CPUs 14:\n  NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170\n  rcu: rcu_preempt kthread timer wakeup didn't happen for 59984 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402\n  rcu:    Possible timer handling issue on cpu=4 timer-softirq=170\n  rcu: rcu_preempt kthread starved for 59987 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4\n  rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.\n  rcu: RCU grace-period kthread stack dump:\n  task:rcu_preempt     state:I stack:0     pid:16    tgid:16    ppid:2      task_flags:0x208040 flags:0x00000010\n  Call trace:\n   __switch_to+0x100/0x1c8 (T)\n   __schedule+0x2b0/0x710\n   schedule+0x3c/0xc0\n   schedule_timeout+0x88/0x128\n   rcu_gp_fqs_loop+0x12c/0x640\n   rcu_gp_kthread+0x308/0x350\n   kthread+0x10c/0x128\n   ret_from_fork+0x10/0x20\n  rcu: Stack dump where RCU GP kthread last ran:\n  Sending NMI from CPU 2 to CPUs 4:\n  NMI backtrace for cpu 4 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170\n  rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n  rcu:    0-...!: (21 GPs behind) idle=a4a0/0/0x0 softirq=1775/1776 fqs=0 (false positive?)\n  rcu:    3-...!: (28 GPs behind) idle=5b00/0/0x0 softirq=1437/1438 fqs=0 (false positive?)\n  rcu:    7-...!: (21 GPs behind) idle=0c18/0/0x0 softirq=1658/1659 fqs=0 (false positive?)\n  rcu:    8-...!: (21 GPs behind) idle=1418/0/0x0 softirq=1231/1231 fqs=0 (false positive?)\n  rcu:    9-...!: (18 GPs behind) idle=1288/0/0x0 softirq=1440/1440 fqs=0 (false positive?)\n  rcu:    12-...!: (21 GPs behind) idle=ae70/0/0x0 softirq=1339/1339 fqs=0 (false positive?)\n  rcu:    13-...!: (28 GPs behind) idle=02c8/0/0x0 softirq=1785/1787 fqs=0 (false positive?)\n  rcu:    14-...!: (21 GPs behind) idle=f428/0/0x0 softirq=1272/1273 fqs=0 (false positive?)\n  rcu:    15-...!: (21 GPs behind) idle=0fb8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)\n  rcu:    (detected by 5, t=60002 jiffies, g=3677, q=12637 ncpus=16)\n  Sending NMI from CPU 5 to CPUs 0:\n  NMI backtrace for cpu 0 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170\n  Sending NMI from CPU 5 to CPUs 3:\n  NMI backtrace for cpu 3 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170\n  Sending NMI from CPU 5 to CPUs 7:\n  NMI backtrace for cpu 7 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170\n  Sending NMI from CPU 5 to CPUs 8:\n  NMI backtrace for cpu 8 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170\n  Sending NMI from CPU 5 to CPUs 9:\n  NMI backtrace for cpu 9 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170\n  Sending NMI from CPU 5 to CPUs 12:\n  NMI backtrace for cpu 12 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170\n  Sending NMI from CPU 5 to CPUs 13:\n  NMI backtrace for cpu 13 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170\n  Sending NMI from CPU 5 to CPUs 14:\n  NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170\n  Sending NMI from CPU 5 to CPUs 15:\n  NMI backtrace for cpu 15 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170\n  rcu: rcu_preempt kthread timer wakeup didn't happen for 60008 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402\n  rcu:    Possible timer handling issue on cpu=4 timer-softirq=170\n  rcu: rcu_preempt kthread starved for 60011 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4\n  rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.\n  rcu: RCU grace-period kthread stack dump:\n  task:rcu_preempt     state:I stack:0     pid:16    tgid:16    ppid:2      task_flags:0x208040 flags:0x00000010\n  Call trace:\n   __switch_to+0x100/0x1c8 (T)\n   __schedule+0x2b0/0x710\n   schedule+0x3c/0xc0\n   schedule_timeout+0x88/0x128\n   rcu_gp_fqs_loop+0x12c/0x640\n   rcu_gp_kthread+0x308/0x350\n   kthread+0x10c/0x128\n   ret_from_fork+0x10/0x20\n  rcu: Stack dump where RCU GP kthread last ran:\n  Sending NMI from CPU 5 to CPUs 4:\n  NMI backtrace for cpu 4\n  CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.0.0-rc7-next-20260409 #1 PREEMPT(lazy)\n  Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : tick_check_broadcast_expired+0x4/0x40\n  lr : cpu_idle_poll.isra.0+0x54/0x170\n  sp : ffff80008017be20\n  x29: ffff80008017be20 x28: 0000000000000000 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n  x23: 00000000000000c0 x22: ffffb3ce21fad000 x21: 0000000000000004\n  x20: ffffb3ce21fadd50 x19: ffffb3ce21fad000 x18: 0000000000000004\n  x17: 0000000000000000 x16: 0000000000000000 x15: ffffb3ce21fb3b98\n  x14: ffffb3ce21788180 x13: 0000000000000000 x12: 000000124d69be59\n  x11: 00000000000000c0 x10: 0000000000001c80 x9 : ffffb3ce1f8a6e68\n  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000004\n  x5 : ffff00275c3682c8 x4 : 0000000000020a3c x3 : 0000000000000000\n  x2 : 0000000000000004 x1 : ffffb3ce223ca0c0 x0 : ffff002020da2140\n  Call trace:\n   tick_check_broadcast_expired+0x4/0x40 (P)\n   do_idle+0x64/0x130\n   cpu_startup_entry+0x40/0x50\n   secondary_start_kernel+0xe4/0x128\n   __secondary_switched+0xc0/0xc8\n  rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n  rcu:    0-...!: (22 GPs behind) idle=ae48/0/0x0 softirq=1775/1776 fqs=0 (false positive?)\n  rcu:    3-...!: (29 GPs behind) idle=7ce8/0/0x0 softirq=1437/1438 fqs=0 (false positive?)\n  rcu:    7-...!: (22 GPs behind) idle=0df8/0/0x0 softirq=1658/1659 fqs=0 (false positive?)\n  rcu:    8-...!: (22 GPs behind) idle=1548/0/0x0 softirq=1231/1231 fqs=0 (false positive?)\n  rcu:    9-...!: (19 GPs behind) idle=1360/0/0x0 softirq=1440/1440 fqs=0 (false positive?)\n  rcu:    12-...!: (22 GPs behind) idle=af40/0/0x0 softirq=1339/1339 fqs=0 (false positive?)\n  rcu:    13-...!: (29 GPs behind) idle=04e0/0/0x0 softirq=1785/1787 fqs=0 (false positive?)\n  rcu:    14-...!: (22 GPs behind) idle=f528/0/0x0 softirq=1272/1273 fqs=0 (false positive?)\n  rcu:    15-...!: (22 GPs behind) idle=0fd8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)\n  rcu:    (detected by 5, t=60002 jiffies, g=3681, q=13149 ncpus=16)\n\nbut other times, there is no output after it locks up. Is there any\ninitial information I can provide to help debug this? Reverting the\nchange on top of next-20260409 avoids the issue.\n\nCheers,\nNathan\n\n# bad: [3fa7d958829eb9bc3b469ed07f11de3d2804ef71] Add linux-next specific files for 20260409\n# good: [7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594] Merge tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid\ngit bisect start '3fa7d958829eb9bc3b469ed07f11de3d2804ef71' '7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594'\n# bad: [443e04732ac2cdc17e3b90aa2345730a298fab37] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git\ngit bisect bad 443e04732ac2cdc17e3b90aa2345730a298fab37\n# bad: [ea33e83d9fa24b34e79c8df57b8927a8d94deb15] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git\ngit bisect bad ea33e83d9fa24b34e79c8df57b8927a8d94deb15\n# bad: [429057750b3d3a7477df48d17aa605dc47bc2344] Merge branch 'for-next/perf' of https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git\ngit bisect bad 429057750b3d3a7477df48d17aa605dc47bc2344\n# bad: [e98894f89da72f392141d9eecf1c7a8f13faa67f] Merge branch 'mm-stable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm\ngit bisect bad e98894f89da72f392141d9eecf1c7a8f13faa67f\n# good: [668937b7b2256f4b2a982e8f69b07d9ee8f81d36] mm: allow handling of stacked mmap_prepare hooks in more drivers\ngit bisect good 668937b7b2256f4b2a982e8f69b07d9ee8f81d36\n# good: [a0fbc8dd44a27011537268e2a974b1180b848796] Merge branch 'dma-mapping-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git\ngit bisect good a0fbc8dd44a27011537268e2a974b1180b848796\n# good: [8a23051ed8584215b22368e9501f771ef98f0c1d] Merge tag 'pin-init-v7.1' of https://github.com/Rust-for-Linux/linux into rust-next\ngit bisect good 8a23051ed8584215b22368e9501f771ef98f0c1d\n# good: [716b25a9dc20f4fb94d521581331a0565a43f3bb] Merge branch 'urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git\ngit bisect good 716b25a9dc20f4fb94d521581331a0565a43f3bb\n# bad: [1a49dc272e25dae6cbb506a02bb70e0201a1498e] Merge branch 'tip/urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git\ngit bisect bad 1a49dc272e25dae6cbb506a02bb70e0201a1498e\n# good: [30023353b2171cd36b10615a788a985f5caa29e3] Merge branch into tip/master: 'sched/urgent'\ngit bisect good 30023353b2171cd36b10615a788a985f5caa29e3\n# good: [34ef164adaf00982d5f45037a7e37689c4555271] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git\ngit bisect good 34ef164adaf00982d5f45037a7e37689c4555271\n# bad: [4fc7108ff756267ad53ecdeaa1e847d378887511] Merge branch into tip/master: 'timers/urgent'\ngit bisect bad 4fc7108ff756267ad53ecdeaa1e847d378887511\n# bad: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation\ngit bisect bad 1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4\n# good: [82b915051d32a68ea3bbe261c93f5620699ff047] tick/nohz: Fix inverted return value in check_tick_dependency() fast path\ngit bisect good 82b915051d32a68ea3bbe261c93f5620699ff047\n# first bad commit: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation","headers":{"Return-Path":"\n <netfilter-devel+bounces-11815-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=LkPaaR1x;\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-11815-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=\"LkPaaR1x\"","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)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fsprv1dpxz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 11 Apr 2026 06:52:15 +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 548ED3030758\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 20:52:12 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 00A223A6B8A;\n\tFri, 10 Apr 2026 20:52:11 +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 7C4A73806A1;\n\tFri, 10 Apr 2026 20:52:10 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 42AF0C19421;\n\tFri, 10 Apr 2026 20:52:06 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775854330; cv=none;\n b=dUJ+R2M207IBv8ZLgzRkkpbA5FkC44xg1zWgpCgEQ8rSun9AtixU9zqBQErITxUFO3HCNUwJ8ZbAB7+CdRNkRIOwEYr5IVvGKCqUnxH98kL44GbxZ4ykKtQlvNyvX1HcUGGEGxCGUfbtw4wDOQ4t/NbbU7BW4nOHema6WyvLewk=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775854330; c=relaxed/simple;\n\tbh=hBqpsCVdBkMH3lEvzZjgPQlx4m7L2aIZuZIfc35yxMY=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=hLN/nRPfq2mx/s0CxcMimK09y8Fd8p2BA9O3eJlq4jklK6yAdj9Ck3lbjG8Q+/4x5P+bB0VelkzjswFqdLYe1JBkFvaQt9WpGWy208rZAkVNsdKmOCg6nYAmZALETguuZMVe9f1B5lz0u240eqqgYhia3tmc82DUjhUorcwDAVE=","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=LkPaaR1x; 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=1775854330;\n\tbh=hBqpsCVdBkMH3lEvzZjgPQlx4m7L2aIZuZIfc35yxMY=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=LkPaaR1xRFqDx54O67j4HSoPLu47W6nIYCxJYd3O0OcKuVWWFKtVAELoM+emOfe2M\n\t xAq01klxGmncNFQ5pVyXlRfHFRTnDPJBnpYkPrUqUiQyYrT5staWKtvAeQHqrrsOW6\n\t oPi4cb1XEhHPfSDWkLn2bF+VHYrsHqdIhk7J8Cjk7XIYsAOGmp6UUTJhaQlo7/bobw\n\t o4n4v8eliqMr5ecBxiUtoUZYwVvvqYuPczwGAc46iaNI/JLyT9UqQMBTiFxFNZbvIy\n\t 3WGqZiK414YBZAJgDjnJ+f/CGivBXH8I99MTqKZBaBcSEoYu7fOKlCln30wZVvfd6a\n\t tk9PQlaDgsivQ==","Date":"Fri, 10 Apr 2026 13:52:03 -0700","From":"Nathan Chancellor <nathan@kernel.org>","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tFrederic Weisbecker <frederic@kernel.org>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<20260410205203.GA3922321@ax162>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@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=us-ascii","Content-Disposition":"inline","In-Reply-To":"<20260407083247.562657657@kernel.org>"}},{"id":3676052,"web_url":"http://patchwork.ozlabs.org/comment/3676052/","msgid":"<87fr52zfze.ffs@tglx>","list_archive_url":null,"date":"2026-04-10T21:02:13","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:\n>> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n>\n> This change in -next as commit 1c2eabb8805d (\"clockevents: Prevent timer\n> interrupt starvation\") appears to make one of my test machines\n> consistently lock up on boot (at least I never get to userspace). Most\n> of the time I get stall messages such as\n\nCan you please retest the changes I just pushed out into:\n\n   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent\n    \nnamely: d6e152d905bd (\"clockevents: Prevent timer interrupt starvation\")\n\nThanks,\n\n        tglx","headers":{"Return-Path":"\n <netfilter-devel+bounces-11816-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=XeoN5wlC;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11816-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=\"XeoN5wlC\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4fsq7j26kRz1yGb\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 11 Apr 2026 07:05:05 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 2C197305D5D7\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:02:20 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 6940C3A8747;\n\tFri, 10 Apr 2026 21:02:18 +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 E907533D4FB;\n\tFri, 10 Apr 2026 21:02:17 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id B5ACCC19421;\n\tFri, 10 Apr 2026 21:02:16 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775854938; cv=none;\n b=XODcgYs5D3j/k28qwgrhp4WDdOuFuGxA3zcg0N+E1Lb562PVQ2H/Y06p1RLgLsjrp0IarmMOO/qeo8SaxIv3eb76YoZNsCma1dkgSV9SRY+hYyLSVwpWUjse2R6FVTBCJUu13xk2c/T0UlGGLaVlPdL/1Bc1LaW6xV5FIYiQj+Y=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775854938; c=relaxed/simple;\n\tbh=NebN3Wxx3EkDVXNhorgAZBBDdQeK7iIH/y0vHwzj9Oc=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=gYQFqCy/l5K6aShuontPWISBkaFZh2PgZWAHU7Jb8T7N3bb44mVCsvI+MrvJnou1wDp7CkqYb0rmZ6non8jr42GE6BOLbpCtZvXU36Kb+LZzUTBsHjb2d/DRhn8NONJuZS102UM9yWSvnBmg0ctugmWfM49GAsXtX6WF4L+E0QA=","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=XeoN5wlC; 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=1775854937;\n\tbh=NebN3Wxx3EkDVXNhorgAZBBDdQeK7iIH/y0vHwzj9Oc=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=XeoN5wlCW42zNPVn1fPVthkRRoraLHnYocRifeTqIdAYIAyxH4QXSJi6oanAJ4fjT\n\t VaDEbWQKEuIZHoGKXlWknwuem2NTfBhhq7C2FOmhP8EEd+otnyzMWMEBgUJYzB2OjK\n\t InDvmdp2mfRRbw08h1lEoNH+G7PJJtmlfBdPH6TlfI+4s+UP8yrXbAVJ9ufWidLcho\n\t ujtCcO0XusveIPX2RzI8dmBE4QngzbueBungtdvFDMQQFwhQS79pSfO4LqL+Ugomzh\n\t 5tp/HhSwKVO7vTm1pX74h6STU2jQp2drJK+xlkfSmyAdoadaHFCxKJlrbofsLv3lTI\n\t 8k9yqcdHTKosg==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Nathan Chancellor <nathan@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>, Anna-Maria Behnsen\n <anna-maria@linutronix.de>, Frederic Weisbecker <frederic@kernel.org>,\n Ingo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>, Stephen\n Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>, Florian\n Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","In-Reply-To":"<20260410205203.GA3922321@ax162>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org> <20260410205203.GA3922321@ax162>","Date":"Fri, 10 Apr 2026 23:02:13 +0200","Message-ID":"<87fr52zfze.ffs@tglx>","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"}},{"id":3676056,"web_url":"http://patchwork.ozlabs.org/comment/3676056/","msgid":"<20260410211310.GA3924786@ax162>","list_archive_url":null,"date":"2026-04-10T21:13:10","subject":"Re: [patch 01/12] clockevents: Prevent timer interrupt starvation","submitter":{"id":81040,"url":"http://patchwork.ozlabs.org/api/people/81040/","name":"Nathan Chancellor","email":"nathan@kernel.org"},"content":"On Fri, Apr 10, 2026 at 11:02:13PM +0200, Thomas Gleixner wrote:\n> On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:\n> >> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n> >\n> > This change in -next as commit 1c2eabb8805d (\"clockevents: Prevent timer\n> > interrupt starvation\") appears to make one of my test machines\n> > consistently lock up on boot (at least I never get to userspace). Most\n> > of the time I get stall messages such as\n> \n> Can you please retest the changes I just pushed out into:\n> \n>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent\n>     \n> namely: d6e152d905bd (\"clockevents: Prevent timer interrupt starvation\")\n\nHah, funny timing. I can confirm that the following diff against the\nversion in -next appears to fix the issue for me. Thanks for the quick\nresponse!\n\nCheers,\nNathan\n\ndiff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\nindex f63c65881364..7e57fa31ee26 100644\n--- a/kernel/time/tick-broadcast.c\n+++ b/kernel/time/tick-broadcast.c\n@@ -76,8 +76,10 @@ const struct clock_event_device *tick_get_wakeup_device(int cpu)\n  */\n static void tick_broadcast_start_periodic(struct clock_event_device *bc)\n {\n-\tif (bc)\n+\tif (bc) {\n+\t\tbc->next_event_forced = 0;\n \t\ttick_setup_periodic(bc, 1);\n+\t}\n }\n \n /*\n@@ -403,6 +405,7 @@ static void tick_handle_periodic_broadcast(struct clock_event_device *dev)\n \tbool bc_local;\n \n \traw_spin_lock(&tick_broadcast_lock);\n+\ttick_broadcast_device.evtdev->next_event_forced = 0;\n \n \t/* Handle spurious interrupts gracefully */\n \tif (clockevent_state_shutdown(tick_broadcast_device.evtdev)) {\n@@ -696,6 +699,7 @@ static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)\n \n \traw_spin_lock(&tick_broadcast_lock);\n \tdev->next_event = KTIME_MAX;\n+\ttick_broadcast_device.evtdev->next_event_forced = 0;\n \tnext_event = KTIME_MAX;\n \tcpumask_clear(tmpmask);\n \tnow = ktime_get();\n@@ -1063,6 +1067,7 @@ static void tick_broadcast_setup_oneshot(struct clock_event_device *bc,\n \n \n \tbc->event_handler = tick_handle_oneshot_broadcast;\n+\tbc->next_event_forced = 0;\n \tbc->next_event = KTIME_MAX;\n \n \t/*\n@@ -1175,6 +1180,7 @@ void hotplug_cpu__broadcast_tick_pull(int deadcpu)\n \t\t}\n \n \t\t/* This moves the broadcast assignment to this CPU: */\n+\t\tbc->next_event_forced = 0;\n \t\tclockevents_program_event(bc, bc->next_event, 1);\n \t}\n \traw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);","headers":{"Return-Path":"\n <netfilter-devel+bounces-11817-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=sYVC0+sF;\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-11817-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=\"sYVC0+sF\"","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 4fsqKY2zmrz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Sat, 11 Apr 2026 07:13:37 +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 98265302C368\n\tfor <incoming@patchwork.ozlabs.org>; Fri, 10 Apr 2026 21:13:23 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 633053A963A;\n\tFri, 10 Apr 2026 21:13:18 +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 D899933D4FB;\n\tFri, 10 Apr 2026 21:13:17 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 94E41C19421;\n\tFri, 10 Apr 2026 21:13:13 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1775855598; cv=none;\n b=OMA1IYu7Ex8UF3oKxWeAnPaDRNbIO66e2npnPUS06lwFGDY99xuRxtunRghqIk5mrhsFcRBcZxJ19Azq9B7o3vNlzE/sl5kHVdVt5QDO/I/+tz59Ijup32EsTIHrw6rEqf03JBMXpRmrhCAwI9qNykXOnqicWFL5fKhDCQZThSI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1775855598; c=relaxed/simple;\n\tbh=mQJOWz1mk2jWZG3BMZyiHaKvboqLwGGiEp7a3M2LQUs=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=oR69NNZlAwsqimSOOxomu1Z7+JRJ5qsHjPz8WdYwA69M9ApB29bsP9CIrbPCOBYMohfkWlmX+PXFwUd5ltpNfzkP00rtaGUWWMatBiniR2lgDi14G8nTnFkxis4axfFm9DfBm7C6w3sf0cCa1qRX8HmAtdwjDxn3nGb8B9x+70Q=","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=sYVC0+sF; 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=1775855597;\n\tbh=mQJOWz1mk2jWZG3BMZyiHaKvboqLwGGiEp7a3M2LQUs=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=sYVC0+sFX1aEJf0c7xfC4XoWL0ytVF+4O9Zg0r27VZsNFINtVGuLBSAvpvzoxy71D\n\t PHOOg7Pw+a22q9Ql52heJTR0EPgfrVpvHHfk2i8sGQAybjla0xizkCmFq9y2XSO6my\n\t PjDBSifY5eWNykKWXtfAEpTIaiG3vU5ApMNdpJHnXS8n37Ug7rbUmu03jjba8zwK8M\n\t FH29NmCT846ZYG0CtKPChBfmsQQwxha9z6OMzW/1ijB/E/8rjaOcdQeXUWK0y8P+BT\n\t kWVE1WDN9lnbPxQTJPkULlHvz96Gbl+kTW/3oX5ilGPb0lhTLhWY5NgZOJ8BF8bGH3\n\t NPGbvWoCdpbRQ==","Date":"Fri, 10 Apr 2026 14:13:10 -0700","From":"Nathan Chancellor <nathan@kernel.org>","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tFrederic Weisbecker <frederic@kernel.org>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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 01/12] clockevents: Prevent timer interrupt starvation","Message-ID":"<20260410211310.GA3924786@ax162>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <20260410205203.GA3922321@ax162>\n <87fr52zfze.ffs@tglx>","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=us-ascii","Content-Disposition":"inline","In-Reply-To":"<87fr52zfze.ffs@tglx>"}},{"id":3676930,"web_url":"http://patchwork.ozlabs.org/comment/3676930/","msgid":"<68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>","list_archive_url":null,"date":"2026-04-13T21:20:43","subject":"The \"clockevents: Prevent timer interrupt starvation\" patch causes\n lockups","submitter":{"id":93136,"url":"http://patchwork.ozlabs.org/api/people/93136/","name":"Hanabishi","email":"i.r.e.c.c.a.k.u.n+kernel.org@gmail.com"},"content":"On 07/04/2026 08:54, Thomas Gleixner wrote:\n> From: Thomas Gleixner <tglx@kernel.org>\n> \n> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked\n> up in user space. He provided a reproducer, which sets 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> As a first step to prevent this, avoid reprogramming the clock event device\n> when:\n>       - a forced minimum delta event is pending\n>       - the new expiry delta is less then or equal to the minimum delta\n> \n> Thanks to Calvin for providing the reproducer and to Borislav for testing\n> and providing data from his Zen5 machine.\n> \n> The problem is not limited to Zen5, but depending on the underlying\n> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed\n> not necessarily observable.\n> \n> This change serves only as the last resort and further changes will be made\n> to prevent this scenario earlier in the call chain as far as possible.\n> \n> Fixes: d316c57ff6bf (\"[PATCH] clockevents: add core functionality\")\n> Reported-by: Calvin Owens <calvin@wbinvd.org>\n> Signed-off-by: Thomas Gleixner <tglx@kernel.org>\n> Cc: Peter Zijlstra <peterz@infradead.org>\n> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>\n> Cc: Frederic Weisbecker <frederic@kernel.org>\n> Cc: Ingo Molnar <mingo@kernel.org>\n> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/\n> ---\n> V2: Simplified the clockevents code - Peter\n> ---\n>   include/linux/clockchips.h |    2 ++\n>   kernel/time/clockevents.c  |   23 +++++++++++++++--------\n>   kernel/time/hrtimer.c      |    1 +\n>   kernel/time/tick-common.c  |    1 +\n>   kernel/time/tick-sched.c   |    1 +\n>   5 files changed, 20 insertions(+), 8 deletions(-)\n> --- a/include/linux/clockchips.h\n> +++ b/include/linux/clockchips.h\n> @@ -80,6 +80,7 @@ enum clock_event_state {\n>    * @shift:\t\tnanoseconds to cycles divisor (power of two)\n>    * @state_use_accessors:current state of the device, assigned by the core code\n>    * @features:\t\tfeatures\n> + * @next_event_forced:\tTrue if the last programming was a forced event\n>    * @retries:\t\tnumber of forced programming retries\n>    * @set_state_periodic:\tswitch state to periodic\n>    * @set_state_oneshot:\tswitch state to oneshot\n> @@ -108,6 +109,7 @@ struct clock_event_device {\n>   \tu32\t\t\tshift;\n>   \tenum clock_event_state\tstate_use_accessors;\n>   \tunsigned int\t\tfeatures;\n> +\tunsigned int\t\tnext_event_forced;\n>   \tunsigned long\t\tretries;\n>   \n>   \tint\t\t\t(*set_state_periodic)(struct clock_event_device *);\n> --- a/kernel/time/clockevents.c\n> +++ b/kernel/time/clockevents.c\n> @@ -172,6 +172,7 @@ void clockevents_shutdown(struct clock_e\n>   {\n>   \tclockevents_switch_state(dev, CLOCK_EVT_STATE_SHUTDOWN);\n>   \tdev->next_event = KTIME_MAX;\n> +\tdev->next_event_forced = 0;\n>   }\n>   \n>   /**\n> @@ -305,7 +306,6 @@ int clockevents_program_event(struct clo\n>   {\n>   \tunsigned long long clc;\n>   \tint64_t delta;\n> -\tint rc;\n>   \n>   \tif (WARN_ON_ONCE(expires < 0))\n>   \t\treturn -ETIME;\n> @@ -324,16 +324,23 @@ int clockevents_program_event(struct clo\n>   \t\treturn dev->set_next_ktime(expires, dev);\n>   \n>   \tdelta = ktime_to_ns(ktime_sub(expires, ktime_get()));\n> -\tif (delta <= 0)\n> -\t\treturn force ? clockevents_program_min_delta(dev) : -ETIME;\n>   \n> -\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n> -\tdelta = max(delta, (int64_t) dev->min_delta_ns);\n> +\tif (delta > (int64_t)dev->min_delta_ns) {\n> +\t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n> +\t\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> +\t\tif (!dev->set_next_event((unsigned long) clc, dev))\n> +\t\t\treturn 0;\n> +\t}\n>   \n> -\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> -\trc = dev->set_next_event((unsigned long) clc, dev);\n> +\tif (dev->next_event_forced)\n> +\t\treturn 0;\n>   \n> -\treturn (rc && force) ? clockevents_program_min_delta(dev) : rc;\n> +\tif (dev->set_next_event(dev->min_delta_ticks, dev)) {\n> +\t\tif (!force || clockevents_program_min_delta(dev))\n> +\t\t\treturn -ETIME;\n> +\t}\n> +\tdev->next_event_forced = 1;\n> +\treturn 0;\n>   }\n>   \n>   /*\n> --- a/kernel/time/hrtimer.c\n> +++ b/kernel/time/hrtimer.c\n> @@ -1888,6 +1888,7 @@ void hrtimer_interrupt(struct clock_even\n>   \tBUG_ON(!cpu_base->hres_active);\n>   \tcpu_base->nr_events++;\n>   \tdev->next_event = KTIME_MAX;\n> +\tdev->next_event_forced = 0;\n>   \n>   \traw_spin_lock_irqsave(&cpu_base->lock, flags);\n>   \tentry_time = now = hrtimer_update_base(cpu_base);\n> --- a/kernel/time/tick-common.c\n> +++ b/kernel/time/tick-common.c\n> @@ -110,6 +110,7 @@ void tick_handle_periodic(struct clock_e\n>   \tint cpu = smp_processor_id();\n>   \tktime_t next = dev->next_event;\n>   \n> +\tdev->next_event_forced = 0;\n>   \ttick_periodic(cpu);\n>   \n>   \t/*\n> --- a/kernel/time/tick-sched.c\n> +++ b/kernel/time/tick-sched.c\n> @@ -1513,6 +1513,7 @@ static void tick_nohz_lowres_handler(str\n>   \tstruct tick_sched *ts = this_cpu_ptr(&tick_cpu_sched);\n>   \n>   \tdev->next_event = KTIME_MAX;\n> +\tdev->next_event_forced = 0;\n>   \n>   \tif (likely(tick_nohz_handler(&ts->sched_timer) == HRTIMER_RESTART))\n>   \t\ttick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);\n> \n> \n\nHello.\n\nSorry, but this patch as of 7.0 introduced *severe* periodic lockups on my Ryzen 7700X machine.\nI see such messages in the log:\n\nclocksource: Long readout interval, skipping watchdog check: cs_nsec: 2897344852 wd_nsec: 2897356996\n\nReverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the issue for me.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11849-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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=FUFPFDfB;\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-11849-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"FUFPFDfB\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.208.46","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"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)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fvgMq0KXtz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 07:21:59 +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 B988730532D1\n\tfor <incoming@patchwork.ozlabs.org>; Mon, 13 Apr 2026 21:20:54 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id A2AFC39524A;\n\tMon, 13 Apr 2026 21:20:49 +0000 (UTC)","from mail-ed1-f46.google.com (mail-ed1-f46.google.com\n [209.85.208.46])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id B3C74392C3A\n\tfor <netfilter-devel@vger.kernel.org>; Mon, 13 Apr 2026 21:20:47 +0000 (UTC)","by mail-ed1-f46.google.com with SMTP id\n 4fb4d7f45d1cf-671ab90fc1fso1552059a12.0\n        for <netfilter-devel@vger.kernel.org>;\n Mon, 13 Apr 2026 14:20:47 -0700 (PDT)","from 127.0.0.1 ([94.41.86.134])\n        by smtp.gmail.com with ESMTPSA id\n a640c23a62f3a-b9d6de9b65fsm341457466b.7.2026.04.13.14.20.43\n        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n        Mon, 13 Apr 2026 14:20:45 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776115249; cv=none;\n b=s08mhaPbuCKh6Y4kHZhMRnPP14/pZ1urToMtSWEiS4fLQvvwqG0bOWBY7vT+p1vnnt1cGvEThduqUadda1E4UX70cglLPKRWaJ1vAqSQs3aHScUAatnDgdu9n2D2XEkc42s3HA3zahO3s+KYSUIhi4lpxfYVPphg5bKRfJOUo2A=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776115249; c=relaxed/simple;\n\tbh=+KNjJIKSmLSTNCxVPcEZ/mpl/fmbcdg+ekJWpmUzLyE=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=WpFvY+k6++vntMJT0eh/UwJfNZislZ6RpGc/3WuS7oNMdf0Wj4fZeG/tIUmjR2K0lfpmY/uca82i9P4iV8y0NYZi6ty4GZq3FENrD5EasSQrY2jHs8LRr3zHRGlQH8Xl6Nl1gHwjuPrVm8Paoyb89FcumfxxVUcsz0r7gDRvMoY=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=FUFPFDfB; arc=none smtp.client-ip=209.85.208.46","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=gmail.com; s=20251104; t=1776115246; x=1776720046;\n darn=vger.kernel.org;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender:from\n         :to:cc:subject:date:message-id:reply-to;\n        bh=HTRp+l7/0tc5qrHVhM0cLgoMYRaB+2fMs37hHfn3p50=;\n        b=FUFPFDfBlUqsQjlzjVeiHztRcorXcwfjGERgPESGe9/psCC6l+I/Mp+rH2vC/6jV7P\n         euGgVRQVt3VPARFXtNrHxHTQ1MLmvlMxvqsS8QXeGPfbKWlfa9rOQyzHScVo6WZdZ1Pg\n         fs3cdVdYFn/YDnyZNz6+zDjIr6aQEGtSx9lyFo0QNbktsBMWMJN/EXnc+cYJPqucFrEl\n         AuqODk1fNIe0kfTvh7kvoA28b+AWr4b22pj/cItAs99VoU59OCLYv7cZvFABG3LTp/LQ\n         broC9QkCWF60Tbpy4tUrLOX0cDIjIdIfqA80mgFMSQLwhvZmV3M20lZVl69DUQzJ5KiF\n         vUlw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776115246; x=1776720046;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender\n         :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n         :reply-to;\n        bh=HTRp+l7/0tc5qrHVhM0cLgoMYRaB+2fMs37hHfn3p50=;\n        b=h0g6E/CQxGOYXWMBXyehwWkSsWtZwMpPmpjI5/FtX+ZugXlipGIihEH6wI/pzHtF0+\n         3GXPWJhQXHZUWZNC1cT4fSxlmDhDu8BspvkUnl4qvkhA7cQnreNUoBjh7KSCUAQtDYxt\n         LrlmbgwIuaV9QFqjG97EBBs54qW49ZxhjrowXqlE10uluqmLOoJHQ33DGboDQ4yDsNHz\n         7h3BKzcxeuNNhCljE0LBh9m9XCP78pV+vfWQLia1KqmUu/9P1OQlYuHRp1klhxLFGFKT\n         39nehHbXVy4OHndKU5Mk/3wnQsJjM6QqGyHRVFnG7Ok5VFm/dMvU1v2tlWfnlRy7ryBy\n         dU1w==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/MlhZePyX51iqSDuCN4M4ixCDO4r9VQCOg0KSgY8t7rl+6vHrdBIDr6QuKyOpyYAbofVnoJutyrAQxIBnlYz4=@vger.kernel.org","X-Gm-Message-State":"AOJu0YwP3uYXq9va3eixC55ODABcXt8zX37VqVoESygi9UVsUyyIP9Sq\n\theod/LKXctfjhB9HK5tcr3Ug1ve+ggnCUMt4Lh2v8PzBcTsJBxCfranf","X-Gm-Gg":"AeBDietSMi7VxQCKAyZ4sOWzsk3rMA6c4ZQPus7BkWq8zE2xdcpUc9PACHS/ZTmUy4g\n\taaLc7ju6AY7sZqUlhwUOcr9yvQBF8xrBPoZrfBfxgmiFnLY1aCwMA5QgksHO3Z9Rf1Jj8Yuh20K\n\t4Hjj2AO3qg67LSlWogxHsR1mfIhWipLmCT00bZZRwJDT8HbYheNVvT2Sk1OQGTAKvWSXqQbDNnc\n\tbsPMOYOvUmNBhW5C4eeFi+ZMtv/OKqyHC2vcemCO3NJHbLTX0A5m6wxgOkjWFHVCZzA4vKeDptl\n\tM5/1PWRce0YVGB8/xVcpVzAnTq0nX+ZW95LbVCnJNy9Z6qJTiBOl5JHedFuYHozOX12eAYCBoIo\n\tZHyUtvv6GlLnGeOqXZgMWDcEW8DLJVdnChNjRw+ZmoIQ5529KhhzVx6WOreZ3SXDqrLeGNwsRYn\n\tWaZQ6XmIFjDD4yFHgKHt3waBbGEBq+mRhvhppL96RBeNU=","X-Received":"by 2002:a17:906:6a0f:b0:b9b:3a1b:e2ec with SMTP id\n a640c23a62f3a-b9d7248abc2mr747543566b.14.1776115245800;\n        Mon, 13 Apr 2026 14:20:45 -0700 (PDT)","Sender":"<irecca.kun@gmail.com>","Message-ID":"<68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>","Date":"Mon, 13 Apr 2026 21:20:43 +0000","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","Subject":"The \"clockevents: Prevent timer interrupt starvation\" patch causes\n lockups","To":"Thomas Gleixner <tglx@kernel.org>, LKML <linux-kernel@vger.kernel.org>","Cc":"Calvin Owens <calvin@wbinvd.org>, Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>,\n Frederic Weisbecker <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>,\n John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,\n Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>","Content-Language":"en-US","From":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>","In-Reply-To":"<20260407083247.562657657@kernel.org>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit"}},{"id":3677289,"web_url":"http://patchwork.ozlabs.org/comment/3677289/","msgid":"<aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>","list_archive_url":null,"date":"2026-04-14T15:39:00","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":91359,"url":"http://patchwork.ozlabs.org/api/people/91359/","name":"Eric Naim","email":"dnaim@cachyos.org"},"content":"On 4/14/26 5:20 AM, Hanabishi wrote:\n> \n> Hello.\n> \n> Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my\n> Ryzen 7700X machine.\n> I see such messages in the log:\n> \n> clocksource: Long readout interval, skipping watchdog check: cs_nsec:\n> 2897344852 wd_nsec: 2897356996\n> \n> Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the\n> issue for me.\n> \n\nHi maintainers,\n\nseveral users from CachyOS has reported this regression as well. We landed on\nthe same bisection. One of the users that could reproduce this reliably\nreproduced this just by watching a YouTube video in a browser, and observed\nfreezes and stutters when interacting with the system.\n\nI had an LLM generate a fix (patch attached), and it fixed the regression for\nthat user. Full disclosure: it is written completely by AI, and I am also not\nfamiliar with this subsystem. I just hope that this patch can be helpful in\nfixing the regression.\n\nPlease don't hesitate to tell me off if utilizing AI in this way is not\nhelpful, so I can keep this in mind for future contributions.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11884-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 secure) header.d=cachyos.org header.i=@cachyos.org header.a=rsa-sha256\n header.s=dkim header.b=N8DG4Rra;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11884-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=\"N8DG4Rra\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.61.224.105","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=cachyos.org"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\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 4fw7v30K1xz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 01:47:11 +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 BE73D30BDCAE\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 15:40:15 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 744143EC2E6;\n\tTue, 14 Apr 2026 15:40:10 +0000 (UTC)","from mail.ptr1337.dev (mail.ptr1337.dev [202.61.224.105])\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 A51673D8135;\n\tTue, 14 Apr 2026 15:40:08 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 64A0528601B;\n\tTue, 14 Apr 2026 17:39:48 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776181210; cv=none;\n b=gEpzTYWjdjZqAnyfXTgfe6L4unacXjhjAi5Sn0WQ+HUXk9WTtYQ4P/fXfl3eBMozQ2KfONcLOLo697l1kbJxsNTxu4c88xPblthU640zWVOpzEs2U1j3pzD1W2dPBGSjQpm45R9pIRMKsfSK/NdBm2gn5VXGHMJJbjY6NVsPw98=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776181210; c=relaxed/simple;\n\tbh=/hbq9f62sy3zTymZ/tCBjj9yBX6FjRzT54Jp86YE5Eg=;\n\th=Content-Type:Message-ID:Date:MIME-Version:Subject:To:Cc:\n\t References:From:In-Reply-To;\n b=H6uCUy6l5hv67WyOVwctig9mfckXwxqiVjJtCdzENA0MmchRLg4yQMiXawFn9pfGf7MqvKXcZ6wDqCiGb1cSqdmEgEy8+rqBRG1huCL288hq+aXSZ2DVmxJgJM7PS3lBFWj8JuAy2iFqCpqg3zlbBy+VEt6I6LmafrfxapPUeyg=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org;\n spf=pass smtp.mailfrom=cachyos.org;\n dkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=N8DG4Rra; arc=none smtp.client-ip=202.61.224.105","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=cachyos.org; s=dkim;\n\tt=1776181206; h=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t in-reply-to:references; bh=TRkUVuOQeq5Z5SjZhRD6qZFJgCtwbDEy/Asrr2F24NA=;\n\tb=N8DG4Rra4KLwOyKjeHa+N8iEQYdRlSKj88SKiopR37J/JDfRZtyzFNNDIeADwcch505Xy8\n\tYSkqXZ+wIuGDmsHnsYuXzbuPYi6dYmv6kzI+0ByILJd5aD2wKKN/RqxgSVjeuHuLbSsups\n\tCFwXntF75VWv1dsYJMwdr7RdfS4ZATCJgIiMthF5LMGV+ISVVfzxGcZu4rKQpXXeoxYrZT\n\t/wGKLdLpqAaxOWbZnle3hAk7QtnMDUsL9EzNi9oWlIajDQ8jqy0QrooOD4J40oLsmmtYx7\n\tAV4zSYlpt/dun2f9rDKasT0jynylvaiSd6hKEV53/75HZsaqcJ0NxkrrPZAFiQ==","Content-Type":"multipart/mixed; boundary=\"------------vQ8liQkI7bMgytpMGm0FanKR\"","Message-ID":"<aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>","Date":"Tue, 14 Apr 2026 15:39:00 +0000","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","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","To":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>,\n Thomas Gleixner <tglx@kernel.org>, LKML <linux-kernel@vger.kernel.org>","Cc":"Calvin Owens <calvin@wbinvd.org>, Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>,\n Frederic Weisbecker <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>,\n John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,\n Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>","From":"Eric Naim <dnaim@cachyos.org>","In-Reply-To":"<68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3677325,"web_url":"http://patchwork.ozlabs.org/comment/3677325/","msgid":"<ad54kGakZkvCoRaT@mozart.vkv.me>","list_archive_url":null,"date":"2026-04-14T17:25:36","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":91507,"url":"http://patchwork.ozlabs.org/api/people/91507/","name":"Calvin Owens","email":"calvin@wbinvd.org"},"content":"On Tuesday 04/14 at 15:39 +0000, Eric Naim wrote:\n> On 4/14/26 5:20 AM, Hanabishi wrote:\n> > \n> > Hello.\n> > \n> > Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my\n> > Ryzen 7700X machine.\n> > I see such messages in the log:\n> > \n> > clocksource: Long readout interval, skipping watchdog check: cs_nsec:\n> > 2897344852 wd_nsec: 2897356996\n> > \n> > Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the\n> > issue for me.\n> > \n> \n> Hi maintainers,\n> \n> several users from CachyOS has reported this regression as well. We landed on\n> the same bisection. One of the users that could reproduce this reliably\n> reproduced this just by watching a YouTube video in a browser, and observed\n> freezes and stutters when interacting with the system.\n\nHuh, I can't reproduce this at all across 10+ machines. Can you share\nthe Kconfig you're seeing this on?\n\nThanks,\nCalvin","headers":{"Return-Path":"\n <netfilter-devel+bounces-11887-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 secure) header.d=wbinvd.org header.i=@wbinvd.org header.a=rsa-sha256\n header.s=wbinvd header.b=XCG7he9g;\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-11887-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org\n header.b=\"XCG7he9g\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=74.125.82.48","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=wbinvd.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=wbinvd.org"],"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 4fwB5s28y0z1xtJ\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 03:26:41 +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 6ABB93018758\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 17:26:00 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5A4A93EDAD6;\n\tTue, 14 Apr 2026 17:25:52 +0000 (UTC)","from mail-dl1-f48.google.com (mail-dl1-f48.google.com\n [74.125.82.48])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E04E3EE1C0\n\tfor <netfilter-devel@vger.kernel.org>; Tue, 14 Apr 2026 17:25:41 +0000 (UTC)","by mail-dl1-f48.google.com with SMTP id\n a92af1059eb24-12c565476d7so3065621c88.1\n        for <netfilter-devel@vger.kernel.org>;\n Tue, 14 Apr 2026 10:25:41 -0700 (PDT)","from mozart.vkv.me ([2001:5a8:468b:d015:93b7:bacf:b594:6a9])\n        by smtp.gmail.com with ESMTPSA id\n 5a478bee46e88-2d940083f49sm9555914eec.13.2026.04.14.10.25.37\n        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n        Tue, 14 Apr 2026 10:25:38 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776187546; cv=none;\n b=Y1zzbuqkg7bYBu4x/7Etsvgctb5ZuXW5/X+74dCiwP698YhQuwRk7ZL419D1Z+8EzdNO1kc8HMyprXnbwFIo0noU3pJ5n5J0FtSNtkZP8ruAaMssMW0RA82u97nbtrAnMIbCRWWvemZBUeEFYoNAGHxH1AXZhzju+EY5ywPc/U0=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776187546; c=relaxed/simple;\n\tbh=Q9Li6IEfFolCG0UHL7CcRmbINp9qWSGmAYv9wveCFmc=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=CQeYaKRyRatQ3xYClVmHy/0uohOXRBDE9Ti2vpOhuP3EuvJWJUQE4+DKIAXUKdVhrbMP0wohXn0O8jRv+X+RRjWfQl55xBWF7mQH2MEmtUJwSc+x5kT0UxEHFBWq7LmGcdE4OaqZYtzMQegCWiuB6VteXR+mSFvogS2y81MSeV4=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=wbinvd.org;\n spf=pass smtp.mailfrom=wbinvd.org;\n dkim=pass (2048-bit key) header.d=wbinvd.org header.i=@wbinvd.org\n header.b=XCG7he9g; arc=none smtp.client-ip=74.125.82.48","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=wbinvd.org; s=wbinvd; t=1776187539; x=1776792339;\n darn=vger.kernel.org;\n        h=in-reply-to:content-disposition:mime-version:references:message-id\n         :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;\n        bh=v0I/6gn6yL3+F/vGBALh7XtrJMo526TaxSYPqk338Bo=;\n        b=XCG7he9gu5CmHUOaYVyo/KsBRc3L1Oaz48GijqjD7WqC1zm4NYbY0Sgyz0CRFHYqTh\n         6U7Ewt6HUoKacTF7Oqpo5/Yc+KqvLHxyIRs33HFyhUEECMDB3cSJO9enKKiuV4BDIjMC\n         w049v07J+r2JrHRSN0CNG75T4m4itaF+kTaCK+pKj+dTvLteBGjVG0QF1ZSMGkJjH1zO\n         Mo3ji9BjDTYtSt/sRwUyF3NZbVJR4ERPt3YQViRLZxKRD70Z6HSoClxzpsfGkiUdyQJv\n         cz4LQmv2H5YnWWPVgy+tF8Kd8eRmoVdhyVVXMBpWD165F3AE3T2MoecHp8zlHJNsqgRa\n         jWxQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776187539; x=1776792339;\n        h=in-reply-to:content-disposition:mime-version:references:message-id\n         :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc\n         :subject:date:message-id:reply-to;\n        bh=v0I/6gn6yL3+F/vGBALh7XtrJMo526TaxSYPqk338Bo=;\n        b=Qw7vu6be9VJS4pVG6iaVQwAQfcGClsIoC1MNP0AoO0pY9G/8d963UfCz+Dds7TI7DF\n         SqhdMNppz48wT+0E6+8wqrsXvKFolC10YEZA3vty/ZAfE5b+4Pza+tBwrjUFdFcEteku\n         rWytIPVkFAX4cxkn00oxDBGv10IqBWyj6umosefQyY6VutdFxIQDkLh/L6GKoRdP+6sd\n         +lbQzZneyKFjK8WZ0HdmDpeaErArhgrU9baU3Hj5c52TwaCRlabzJWCGQ3idzZAtsjpN\n         rI1nppWHBJzSmVND9jXTlLf6Nf2Mca+PXIbgBazBqN2z7lCQUw+ypjRmVKJ/EmrTrUvH\n         WmKA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/rV0Tyjsi8y/5ZA3qaVgN/Cohi8tBAhFlFR1KmFjsxX7htMOgJtJ+rrxksZ9h0kgmuP6TJt7Rg5Mfe0UHGE74=@vger.kernel.org","X-Gm-Message-State":"AOJu0YyPgj/gGbvCWbNrnmG04K5CDhVrWmdgq4Fhgof30qJzSJEqMbN4\n\tTU6jgavjSKSiF4q/V36tApqyLnpzeDSOdZc2yaS6GR2IORnxn0ZreFMsA3lOb3wVdkI=","X-Gm-Gg":"AeBDiev0rMQpkdKBxdPnR+GsGpJ8GxCzZkK3mQzGg+McYUYDtftq1A7AX9QDE54yIbr\n\tHfqNtjPZRNADKMiy7xERMdW7CBaz/GoXVTxcwzTnK/e35kMk4pR+GM7kLgAQCEhLiZbNuENycrA\n\tfekF072CwVIW5drgunxQpVCz4QPU4rxUhxKLaFqCtsxXGNb3j0ZuJUZRAwq0pFDlpBYwZqD/5/i\n\t4Qx2YU1gtK/acD9P8YdmbM0ZIDMH7alTLeDHK1SY6c3AU0ZXvysjZ151CUGZUnfsaUKcrvhJDDC\n\tomf9/uF9DcK9bMvU+xOQdqJMa3hE8VrEaprw7hl3STB+kZfN+qAKLXk/Fv9vB5qCyK+nMkMQTUe\n\tkZsleKSUHVs2W0wc3zEd1L5oA1hEhk99tX029XjT2feLjfzgmKk96quzPk4SAaWyIyOhPSvfHkc\n\tKFUR8Z7YpNg7ZLwB16f+8z4UhK","X-Received":"by 2002:a05:7022:eac5:b0:128:d2b3:5df with SMTP id\n a92af1059eb24-12c34ecea05mr10134040c88.23.1776187539356;\n        Tue, 14 Apr 2026 10:25:39 -0700 (PDT)","Date":"Tue, 14 Apr 2026 10:25:36 -0700","From":"Calvin Owens <calvin@wbinvd.org>","To":"Eric Naim <dnaim@cachyos.org>","Cc":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>,\n\tThomas Gleixner <tglx@kernel.org>,\n\tLKML <linux-kernel@vger.kernel.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tFrederic Weisbecker <frederic@kernel.org>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","Message-ID":"<ad54kGakZkvCoRaT@mozart.vkv.me>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.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=utf-8","Content-Disposition":"inline","In-Reply-To":"<aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>"}},{"id":3677351,"web_url":"http://patchwork.ozlabs.org/comment/3677351/","msgid":"<ad6BtKRj1GyreNCS@localhost.localdomain>","list_archive_url":null,"date":"2026-04-14T18:04:36","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":79411,"url":"http://patchwork.ozlabs.org/api/people/79411/","name":"Frederic Weisbecker","email":"frederic@kernel.org"},"content":"Le Tue, Apr 14, 2026 at 03:39:00PM +0000, Eric Naim a écrit :\n> On 4/14/26 5:20 AM, Hanabishi wrote:\n> > \n> > Hello.\n> > \n> > Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my\n> > Ryzen 7700X machine.\n> > I see such messages in the log:\n> > \n> > clocksource: Long readout interval, skipping watchdog check: cs_nsec:\n> > 2897344852 wd_nsec: 2897356996\n> > \n> > Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the\n> > issue for me.\n> > \n> \n> Hi maintainers,\n> \n> several users from CachyOS has reported this regression as well. We landed on\n> the same bisection. One of the users that could reproduce this reliably\n> reproduced this just by watching a YouTube video in a browser, and observed\n> freezes and stutters when interacting with the system.\n> \n> I had an LLM generate a fix (patch attached), and it fixed the regression for\n> that user. Full disclosure: it is written completely by AI, and I am also not\n> familiar with this subsystem. I just hope that this patch can be helpful in\n> fixing the regression.\n> \n> Please don't hesitate to tell me off if utilizing AI in this way is not\n> helpful, so I can keep this in mind for future contributions.\n> \n> \n> -- \n> Regards,\n>   Eric\n\n> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\n> index 38570998a19b..37b10045572e 100644\n> --- a/kernel/time/clockevents.c\n> +++ b/kernel/time/clockevents.c\n> @@ -332,8 +332,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,\n>  \tif (delta > (int64_t)dev->min_delta_ns) {\n>  \t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n>  \t\tclc = ((unsigned long long) delta * dev->mult) >> dev->shift;\n> -\t\tif (!dev->set_next_event((unsigned long) clc, dev))\n> +\t\tif (!dev->set_next_event((unsigned long) clc, dev)) {\n> +\t\t\tdev->next_event_forced = 0;\n>  \t\t\treturn 0;\n> +\t\t}\n>  \t}\n>  \n>  \tif (dev->next_event_forced)\n> diff --git a/kernel/time/tick-oneshot.c b/kernel/time/tick-oneshot.c\n> index 7472597f3225..bf411472d4f7 100644\n> --- a/kernel/time/tick-oneshot.c\n> +++ b/kernel/time/tick-oneshot.c\n> @@ -34,6 +34,7 @@ int tick_program_event(ktime_t expires, int force)\n>  \t\t */\n>  \t\tclockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT_STOPPED);\n>  \t\tdev->next_event = KTIME_MAX;\n> +\t\tdev->next_event_forced = 0;\n>  \t\treturn 0;\n>  \t}\n>  \n> @@ -43,6 +44,7 @@ int tick_program_event(ktime_t expires, int force)\n>  \t\t * before using it.\n>  \t\t */\n>  \t\tclockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT);\n> +\t\tdev->next_event_forced = 0;\n>  \t}\n>  \n>  \treturn clockevents_program_event(dev, expires, force);\n\nThat diff suggest that dev->next_event_forced is not properly cleared by\na handler or when the device is stopped.\n\nFor example it's not cleared when the device is oneshot stopped.\n\nIt's also not cleared when the device is detached (though that shouldn't\nmatter much) and also when the broadcast wakeup thing is used.\n\nCan you try the following?\n\ndiff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\nindex b4d730604972..5c6dfd6bed28 100644\n--- a/kernel/time/clockevents.c\n+++ b/kernel/time/clockevents.c\n@@ -100,6 +100,7 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n \t\t/* The clockevent device is getting replaced. Shut it down. */\n \n \tcase CLOCK_EVT_STATE_SHUTDOWN:\n+\t\tdev->next_event_forced = 0;\n \t\tif (dev->set_state_shutdown)\n \t\t\treturn dev->set_state_shutdown(dev);\n \t\treturn 0;\n@@ -127,10 +128,12 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n \t\t\t      clockevent_get_state(dev)))\n \t\t\treturn -EINVAL;\n \n-\t\tif (dev->set_state_oneshot_stopped)\n+\t\tif (dev->set_state_oneshot_stopped) {\n+\t\t\tdev->next_event_forced = 0;\n \t\t\treturn dev->set_state_oneshot_stopped(dev);\n-\t\telse\n+\t\t} else {\n \t\t\treturn -ENOSYS;\n+\t\t}\n \n \tdefault:\n \t\treturn -ENOSYS;\ndiff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\nindex 7e57fa31ee26..115e0bf01276 100644\n--- a/kernel/time/tick-broadcast.c\n+++ b/kernel/time/tick-broadcast.c\n@@ -108,6 +108,7 @@ static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu)\n \n static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)\n {\n+\twd->next_event_forced = 0;\n \t/*\n \t * If we woke up early and the tick was reprogrammed in the\n \t * meantime then this may be spurious but harmless.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11888-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=SItFgwXN;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11888-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=\"SItFgwXN\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwC3012B0z1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 04:09:16 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 1EDA3307D0B4\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 18:04:42 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 85C0531328E;\n\tTue, 14 Apr 2026 18:04:40 +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 0911D248166;\n\tTue, 14 Apr 2026 18:04:39 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 3D36DC19425;\n\tTue, 14 Apr 2026 18:04:39 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776189880; cv=none;\n b=MZ80eeUYqXYFf7d79cMxMwMHQNs+RdnF2sd2XGCFoGsQ15V5hVelJS7WJRLophORPl6Wo1Va29uuOLbjA2LFsHEVubT1ldTa61jMpUg2wuJvvt2JftwBY4+1WMONduyEqgAMuN1yQ5SK0iaGKLmVat7fn1PI+wRUPDJ4Jc7fyCo=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776189880; c=relaxed/simple;\n\tbh=iR7rlrGmwA/rHAX7iIBtarDaDTWAcc7zO/ecbr5nem8=;\n\th=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:\n\t Content-Type:Content-Disposition:In-Reply-To;\n b=Eun3raj8kHWgjjUjKChkFcCiW6T9WBPVWU4O19sjS5HzKCuSv6f22a2QEdo564RzTcH7qUHdIw6fSOQKs9F1B5KnjlmPHYHX7g/UPBvA+HFXirH84f82+W/Gz9vdpykqGsHqiubJPAqJCouT/sZdOvNRtshlAjermcsWgMt93iA=","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=SItFgwXN; 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=1776189879;\n\tbh=iR7rlrGmwA/rHAX7iIBtarDaDTWAcc7zO/ecbr5nem8=;\n\th=Date:From:To:Cc:Subject:References:In-Reply-To:From;\n\tb=SItFgwXNnrWiBMII6fkX82ETct3p5t0zsp5Sq1G712Zw7c0tO3M49217Bs6JOnTtP\n\t l2r3+F6zbLRk/wXIputOEMrbAEzfYhqiJNrVklo82qAMJMnQkmH1yfJkYODdZ3/g+Y\n\t PG87DYavrhwzXiBx5hqPgjVJt+lEUaJyyGkgP8WhGUKIPaygOGT/uIQGec6zDy+55n\n\t x/kBiqbxEQV8WL1hm8JD8qsi959poFXqctAmhqtmWalm877JgmefZkyJKhZ6zc2Uoa\n\t MEJR4H5/u73eZ9viNG+uL4xQ7qNyJZkWMdpoDAi7DfiGwOnoi2ph7+YVjNkuVT/kmV\n\t mZlBSAUJW/Liw==","Date":"Tue, 14 Apr 2026 20:04:36 +0200","From":"Frederic Weisbecker <frederic@kernel.org>","To":"Eric Naim <dnaim@cachyos.org>","Cc":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>,\n\tThomas Gleixner <tglx@kernel.org>,\n\tLKML <linux-kernel@vger.kernel.org>,\n\tCalvin Owens <calvin@wbinvd.org>,\n\tPeter Zijlstra <peterz@infradead.org>,\n\tAnna-Maria Behnsen <anna-maria@linutronix.de>,\n\tIngo Molnar <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n\tStephen 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: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","Message-ID":"<ad6BtKRj1GyreNCS@localhost.localdomain>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.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":"<aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>"}},{"id":3677356,"web_url":"http://patchwork.ozlabs.org/comment/3677356/","msgid":"<3a35daf9-edc5-4b41-b784-7b667d2738ba@cachyos.org>","list_archive_url":null,"date":"2026-04-14T18:19:00","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":91359,"url":"http://patchwork.ozlabs.org/api/people/91359/","name":"Eric Naim","email":"dnaim@cachyos.org"},"content":"On 4/15/26 1:25 AM, Calvin Owens wrote:\n> On Tuesday 04/14 at 15:39 +0000, Eric Naim wrote:\n>> On 4/14/26 5:20 AM, Hanabishi wrote:\n>>>\n>>> Hello.\n>>>\n>>> Sorry, but this patch as of 7.0 introduced *severe* periodic lockups on my\n>>> Ryzen 7700X machine.\n>>> I see such messages in the log:\n>>>\n>>> clocksource: Long readout interval, skipping watchdog check: cs_nsec:\n>>> 2897344852 wd_nsec: 2897356996\n>>>\n>>> Reverting d6e152d905bdb1f32f9d99775e2f453350399a6a for mainline fixes the\n>>> issue for me.\n>>>\n>>\n>> Hi maintainers,\n>>\n>> several users from CachyOS has reported this regression as well. We landed on\n>> the same bisection. One of the users that could reproduce this reliably\n>> reproduced this just by watching a YouTube video in a browser, and observed\n>> freezes and stutters when interacting with the system.\n> \n> Huh, I can't reproduce this at all across 10+ machines. Can you share\n> the Kconfig you're seeing this on?\n\nRight, here it is [1]. CachyOS does carry a lot of downstream patches, but I\nmade sure to reproduce this on mainline before reporting here.\n\n[1]\nhttps://github.com/CachyOS/linux-cachyos/blob/4224303b6d7a50dd1cc3ffa78864050cc9536eec/linux-cachyos/config\n\n> \n> Thanks,\n> Calvin","headers":{"Return-Path":"\n <netfilter-devel+bounces-11889-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 secure) header.d=cachyos.org header.i=@cachyos.org header.a=rsa-sha256\n header.s=dkim header.b=OxN7zcLq;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11889-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=\"OxN7zcLq\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.61.224.105","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=cachyos.org"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::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 4fwCHV42BPz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 04:20:06 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 5C1A13012BCC\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 18:20:01 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 7FD8531AAB8;\n\tTue, 14 Apr 2026 18:19:57 +0000 (UTC)","from mail.ptr1337.dev (mail.ptr1337.dev [202.61.224.105])\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 C4DF1239085;\n\tTue, 14 Apr 2026 18:19:55 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 4300D285DF2;\n\tTue, 14 Apr 2026 20:19:39 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776190797; cv=none;\n b=GOaAHQ8AXFBcBnrlDSg3EtXrb5J0vyvy7PsiykqP77doqgNBf/no4GaQdcpL99b1HDMX5uiUIZucwZokXm0kf7DcIqqvEnPTPsrJziVNozsyoQXm/U4BCkOABYMJmUZkxGio5f5g9kQf1JKsKfhs7FOZ8S6qDJ+LW73zImKeuYM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776190797; c=relaxed/simple;\n\tbh=7NLIVLEo1oZ9lp8JK2MqQPj3X/eSvySWABd833ymfEY=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=SBG0hV+HH2uL449R4nbfhm8CZUBnwo8XxX27laXMlQOw7qWw2s83QYq+0m6Nu7kFVKIK81pODQi0fHDJ0ixinHJA1OROp9n3dcnvNIe0rpIk4/YDnfVdC00P/XYNUWIBLal4KocjNVzvLxmC9JG5C8NVNu/uK0UJ87/2+96R6oQ=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org;\n spf=pass smtp.mailfrom=cachyos.org;\n dkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=OxN7zcLq; arc=none smtp.client-ip=202.61.224.105","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=cachyos.org; s=dkim;\n\tt=1776190787; h=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:in-reply-to:references;\n\tbh=QhA6fInA9ev/sumb0+jecuGAIgHW/ts30uXmTk7kTpU=;\n\tb=OxN7zcLqTH8SXiH6uWGZDIq0dKmbqVcDaJl9R/REPhY09HJCaxP1yGVKfmHVlwon7nGTnz\n\tWVskt5RD60gh5TrFWYeXi1N0UJrNp3OLq9eqklJuIa7Mr8r2SWl/vUNxk7CeVYQd9uz4f3\n\tv0Lb/ZrUJuMbsYfRJ9J9pSn9d8cmz7F52sQdb2OYjCFN6fPXcyPCklnIL+JLdgVRnG6m47\n\tXz0zhnqWwHbthKjgOH1e06PbSf9MFkMLSwo7mD/33PKsXRCz74beFpwoT8TwYkVs00S97i\n\tjC7V+42+8JmZx+KaK9Z0EjVxBy7U71KXTnEiuMFMEcjRSqLwYQK+H1HV+rAyxQ==","Message-ID":"<3a35daf9-edc5-4b41-b784-7b667d2738ba@cachyos.org>","Date":"Tue, 14 Apr 2026 18:19:00 +0000","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","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","To":"Calvin Owens <calvin@wbinvd.org>","Cc":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>,\n Thomas Gleixner <tglx@kernel.org>, LKML <linux-kernel@vger.kernel.org>,\n Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>,\n Frederic Weisbecker <frederic@kernel.org>, Ingo Molnar <mingo@kernel.org>,\n John Stultz <jstultz@google.com>, Stephen Boyd <sboyd@kernel.org>,\n Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>\n <ad54kGakZkvCoRaT@mozart.vkv.me>","From":"Eric Naim <dnaim@cachyos.org>","In-Reply-To":"<ad54kGakZkvCoRaT@mozart.vkv.me>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Last-TLS-Session-Version":"TLSv1.3"}},{"id":3677357,"web_url":"http://patchwork.ozlabs.org/comment/3677357/","msgid":"<a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com>","list_archive_url":null,"date":"2026-04-14T18:25:28","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":93136,"url":"http://patchwork.ozlabs.org/api/people/93136/","name":"Hanabishi","email":"i.r.e.c.c.a.k.u.n+kernel.org@gmail.com"},"content":"On 14/04/2026 18:04, Frederic Weisbecker wrote:\n> Can you try the following?\n> \n> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\n> index b4d730604972..5c6dfd6bed28 100644\n> --- a/kernel/time/clockevents.c\n> +++ b/kernel/time/clockevents.c\n> @@ -100,6 +100,7 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n>   \t\t/* The clockevent device is getting replaced. Shut it down. */\n>   \n>   \tcase CLOCK_EVT_STATE_SHUTDOWN:\n> +\t\tdev->next_event_forced = 0;\n>   \t\tif (dev->set_state_shutdown)\n>   \t\t\treturn dev->set_state_shutdown(dev);\n>   \t\treturn 0;\n> @@ -127,10 +128,12 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n>   \t\t\t      clockevent_get_state(dev)))\n>   \t\t\treturn -EINVAL;\n>   \n> -\t\tif (dev->set_state_oneshot_stopped)\n> +\t\tif (dev->set_state_oneshot_stopped) {\n> +\t\t\tdev->next_event_forced = 0;\n>   \t\t\treturn dev->set_state_oneshot_stopped(dev);\n> -\t\telse\n> +\t\t} else {\n>   \t\t\treturn -ENOSYS;\n> +\t\t}\n>   \n>   \tdefault:\n>   \t\treturn -ENOSYS;\n> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\n> index 7e57fa31ee26..115e0bf01276 100644\n> --- a/kernel/time/tick-broadcast.c\n> +++ b/kernel/time/tick-broadcast.c\n> @@ -108,6 +108,7 @@ static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu)\n>   \n>   static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)\n>   {\n> +\twd->next_event_forced = 0;\n>   \t/*\n>   \t * If we woke up early and the tick was reprogrammed in the\n>   \t * meantime then this may be spurious but harmless.\n\nThis patch doesn't help me unfortunately. Thanks.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11890-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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=Ytag37WK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11890-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"Ytag37WK\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.218.43","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4fwCY14xkVz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 04:31:49 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 0C6FD30BD145\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 18:25:37 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 5A65D31B80E;\n\tTue, 14 Apr 2026 18:25:36 +0000 (UTC)","from mail-ej1-f43.google.com (mail-ej1-f43.google.com\n [209.85.218.43])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 04C4E318EF4\n\tfor <netfilter-devel@vger.kernel.org>; Tue, 14 Apr 2026 18:25:32 +0000 (UTC)","by mail-ej1-f43.google.com with SMTP id\n a640c23a62f3a-b9b1ffbb9f5so829772766b.2\n        for <netfilter-devel@vger.kernel.org>;\n Tue, 14 Apr 2026 11:25:32 -0700 (PDT)","from 127.0.0.1 ([94.41.86.134])\n        by smtp.gmail.com with ESMTPSA id\n a640c23a62f3a-b9d6db92792sm413467066b.0.2026.04.14.11.25.29\n        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n        Tue, 14 Apr 2026 11:25:30 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776191135; cv=none;\n b=FfZD9UlOaegmD61M4lYEc1qfoToAt/vG4KDJTlxt//nHWFucXxORqBMMukOt2tseBQoxGWHWW1k6LO5uYAeG3hTFZB0UYTht8QZwr/y6y8i2XV704XckbSUb2q3IOlX1YcXgcb2nh8wxzhgHB+U/EAJx0dfIqZjV03YlTSXMjfI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776191135; c=relaxed/simple;\n\tbh=G3w0DZ0WFidkPB/uPrbI9py6h5O7bcwpN2Dv7lkGGTQ=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=jEDBD7VpebPNBc0MAZ82A3+oESqAikzsoqHopxJDQMCccu5LKLpMiXRbWsFSRTKdB78xCZ2eBkw7I3XsbAeGGyYtFpLotp3n5XT036iSl8nLOPbqvFgC2TryUc3F0f8uzVqoqxxmlZbjDJRPaQGGrUMIcNG9UaRah6SpemhBYsk=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=Ytag37WK; arc=none smtp.client-ip=209.85.218.43","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=gmail.com; s=20251104; t=1776191131; x=1776795931;\n darn=vger.kernel.org;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender:from\n         :to:cc:subject:date:message-id:reply-to;\n        bh=KPeEClNJ70HwQFmMmwRFDNn5+7Dvy+a0H3+D1LydCmU=;\n        b=Ytag37WKLdbqkETC1go8+hSa41sqknKPK00yveQS2qYT1LiCo/j/KwYrjg2H6iatuU\n         pkDk5rPhf10HFL7dtHqlw48wEu/4U0b6AIYYO1QChHcU7XK9yb9/QxbgJzA2AE3ELtlY\n         KGYvLXE9EQe7/ybeL4Jh+zuPB6NpeQXoi7Gru2woEZDd7z4SPw2SJjEHMsT2W7oMQK13\n         v/o/f5vDunRfIM/PMrFcuRtg05cZOFXRRGIGULmn/sougVse/toHSYm+puqRiPlTNO/C\n         e2MhPpCHeN8e+sbzGpDxvcZfdNM3Bv7T2dNvJOB3oIeaG4a17W7hPKgboELXceXspSH2\n         /0ow==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776191131; x=1776795931;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender\n         :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n         :reply-to;\n        bh=KPeEClNJ70HwQFmMmwRFDNn5+7Dvy+a0H3+D1LydCmU=;\n        b=Ej/8TwlwxdPbrgi8EGTbmmWy0kOI1mxRrHQPsI97ryzeEWf1bNtznqSzMYVeB2L8wm\n         gbNlijETjhECU0X1mJOUKOypik7kvpxJNZ6RB9XOBaYivQqvWnEP+ivHIoaSJDfxnSnJ\n         RSro3uhgfQEyPUzxn27ecqEiVsyJEV/FRjPitVsj0IgNGktSWtIZHwdealHG0q+BzX4b\n         baYLAfGo3vpByIOo3NL9CdGCOi9+g9f29eXPnPWiJQfmtk63wzlyct5Kw770u0/0zE6J\n         viT24gJ2kfCdBVGl6STfyCIx7i9FsE7hhKGpgfRzdMdNMF1cdT1uE2akouv+Lopmxbl8\n         yjvw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ+nNfUBR7n7YzrHVM8MjWV5iNpvWqAIrefa7rcQ+7+XQSgmgbjMRsliBlsStvDbQBtjsorqmpPezEuZ/glSRG0=@vger.kernel.org","X-Gm-Message-State":"AOJu0YyEM5ChvzIW2HxAuRFGUODqQ9spUfv9nf7hbJ+JPVvH/zI2MqWg\n\tBT0Y0mp+7sM8W8hR5yhQsBQb5Pgovmckjk1JM7hC3PuYFD8msJT3b1kC","X-Gm-Gg":"AeBDiesMXOSp70uOugNBl4F9KzFYc+Cmu4/6eSB9WntRqW0Qt219k0kXcMi6BgCaHUc\n\tVun/t3hhUit0P6rhCKcl27D66bMx5NrfaaEQt6Vos2a6qUkvN3D4ezpR/ZO7KygzYFJQC5Py41H\n\tcxBr/awkiorJgCHde+hUclVE6FaH4NYEExFixoiQoPFAQLD9CYbKFYvncpnQel6bKS3qhEKEaxw\n\ttPUMEgyNZdQgcSHlZr/eMNsPDrNC6LIuz1N0bHND+EmuLSnN3khCjelxAnGSpQSIhBYD+daknJE\n\t3XFyTMf0Mh6UW+uhW3/JymuShgGM38X7YwQJu+YU9NKTHlhP3uTd8B36EoysDz9tHbGkiVAzryr\n\tGciFmiRdARGNsOgdCQiKS8N+Ma2FNmx/mGJBk77TnAkzdgb9ufMGDCcE+RSlVfDHIEME+xEylvj\n\tXCq7nadYVIFH0cSMkeLjwvcOWXmgFasZniaf0OpokkdH12K2NMVYQl+w==","X-Received":"by 2002:a17:907:3e0b:b0:b96:e593:fd1e with SMTP id\n a640c23a62f3a-b9d71fe2c9cmr952390666b.0.1776191131309;\n        Tue, 14 Apr 2026 11:25:31 -0700 (PDT)","Sender":"<irecca.kun@gmail.com>","Message-ID":"<a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com>","Date":"Tue, 14 Apr 2026 18:25:28 +0000","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","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","To":"Frederic Weisbecker <frederic@kernel.org>","Cc":"Eric Naim <dnaim@cachyos.org>, Thomas Gleixner <tglx@kernel.org>,\n LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Ingo Molnar\n <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n Stephen Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>\n <ad6BtKRj1GyreNCS@localhost.localdomain>","Content-Language":"en-US","From":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>","In-Reply-To":"<ad6BtKRj1GyreNCS@localhost.localdomain>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit"}},{"id":3677401,"web_url":"http://patchwork.ozlabs.org/comment/3677401/","msgid":"<87340xfeje.ffs@tglx>","list_archive_url":null,"date":"2026-04-14T20:55:01","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":92397,"url":"http://patchwork.ozlabs.org/api/people/92397/","name":"Thomas Gleixner","email":"tglx@kernel.org"},"content":"On Tue, Apr 14 2026 at 18:25, Hanabishi wrote:\n> On 14/04/2026 18:04, Frederic Weisbecker wrote:\n>\n> This patch doesn't help me unfortunately. Thanks.\n\nThe one below should cover all possible holes.\n\nThanks,\n\n        tglx\n---\ndiff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\nindex b4d730604972..5e22697b098d 100644\n--- a/kernel/time/clockevents.c\n+++ b/kernel/time/clockevents.c\n@@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n \tif (dev->features & CLOCK_EVT_FEAT_DUMMY)\n \t\treturn 0;\n \n+\t/* On state transitions clear the forced flag unconditionally */\n+\tdev->next_event_forced = 0;\n+\n \t/* Transition with new state-specific callbacks */\n \tswitch (state) {\n \tcase CLOCK_EVT_STATE_DETACHED:\n@@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b\n \tif (delta > (int64_t)dev->min_delta_ns) {\n \t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n \t\tcycles = ((u64)delta * dev->mult) >> dev->shift;\n-\t\tif (!dev->set_next_event((unsigned long) cycles, dev))\n+\t\tif (!dev->set_next_event((unsigned long) cycles, dev)) {\n+\t\t\tdev->next_event_forced = 0;\n \t\t\treturn 0;\n+\t\t}\n \t}\n \n \tif (dev->next_event_forced)\ndiff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\nindex 7e57fa31ee26..115e0bf01276 100644\n--- a/kernel/time/tick-broadcast.c\n+++ b/kernel/time/tick-broadcast.c\n@@ -108,6 +108,7 @@ static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu)\n \n static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)\n {\n+\twd->next_event_forced = 0;\n \t/*\n \t * If we woke up early and the tick was reprogrammed in the\n \t * meantime then this may be spurious but harmless.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11892-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=G0sc6Cc5;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c0a:e001:db::12fc:5321; helo=sea.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11892-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=\"G0sc6Cc5\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=10.30.226.201"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org\n [IPv6:2600:3c0a:e001:db::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 4fwGkv6Z94z1yD5\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 06:55:35 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 6C4ED304B2BB\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 20:55:09 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 7DA58372ED0;\n\tTue, 14 Apr 2026 20:55:06 +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 0855C275AFB;\n\tTue, 14 Apr 2026 20:55:06 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D4D4BC19425;\n\tTue, 14 Apr 2026 20:55:04 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776200106; cv=none;\n b=kJtsUuDBVXefHlQhixiDXskL0YjfWhxkFSadZRQOTscbw8+REmh9XigA6suwvuO1xF6h9J5EhspXOHt9Ogv+PmR4S6AhfzTHR0JN1cAGNMzq1mUwH2lT6wJFZrEq8Nt4BlGcgyfNTtwaktRCsK3uLuTcfjvHGm7Pcd985RSq/TI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776200106; c=relaxed/simple;\n\tbh=EDu18GVFDioQPQHdsolEuUt692hxrgbWXQqdtx2/xsg=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:\n\t MIME-Version:Content-Type;\n b=MRmLOktNKE03z3AgKUSv+pPN6YubUb+YWi6Kjs00SfnxdAEejgEbTBJ8jOApDaGYjpPQcT5Clzz5cQgFa1siCUnT2ZElHdoPPYpw/Z/FUBhSmmBXt656aDz7p2R4pt6NOXeFr+uYkpca9XmfYr6QdMrahppzQmTBg8zP7HlATws=","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=G0sc6Cc5; 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=1776200105;\n\tbh=EDu18GVFDioQPQHdsolEuUt692hxrgbWXQqdtx2/xsg=;\n\th=From:To:Cc:Subject:In-Reply-To:References:Date:From;\n\tb=G0sc6Cc5UKUVzzxbQ16k8r9RRuAiMS6T5iAx4FH6QLNxGLx0j5r01VxJsc0UD417h\n\t XutpQWK+tHXTGKkkGk97epHbPm5dIxq1J5kTPyN0RhlM3h5JtGpqUHyB6/8kHCXmIc\n\t q/YHMB5/YqKPT8jniFghDr2L2RLBaVfoDHtRb7tvFd24xr3MZrZl6vFA0LPxPQLuHI\n\t aY8bGfCFsTemtxunJfZzCPh8q16CzXn/bRveQzqkEtfEuhc0HZ6dClesGUpEmbP3ku\n\t sTLCgFLw1mpk1zH4kO8fRpK2NcrRYoEnbrCWJ29fYz1+3MZjPjhJJMQL/eTw3BITbx\n\t jKxiG9TqOxECg==","From":"Thomas Gleixner <tglx@kernel.org>","To":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>, Frederic Weisbecker\n <frederic@kernel.org>","Cc":"Eric Naim <dnaim@cachyos.org>, LKML <linux-kernel@vger.kernel.org>,\n Calvin Owens <calvin@wbinvd.org>, Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Ingo Molnar\n <mingo@kernel.org>, John Stultz <jstultz@google.com>, Stephen Boyd\n <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Christian\n Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>, Florian\n Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","In-Reply-To":"<a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com>","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>\n <ad6BtKRj1GyreNCS@localhost.localdomain>\n <a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com>","Date":"Tue, 14 Apr 2026 22:55:01 +0200","Message-ID":"<87340xfeje.ffs@tglx>","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"}},{"id":3677406,"web_url":"http://patchwork.ozlabs.org/comment/3677406/","msgid":"<e6d3dc64-1714-4105-8a38-3942c62d159a@gmail.com>","list_archive_url":null,"date":"2026-04-14T21:35:59","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":93136,"url":"http://patchwork.ozlabs.org/api/people/93136/","name":"Hanabishi","email":"i.r.e.c.c.a.k.u.n+kernel.org@gmail.com"},"content":"On 14/04/2026 20:55, Thomas Gleixner wrote:\n> The one below should cover all possible holes.\n> \n> Thanks,\n> \n>          tglx\n> ---\n> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\n> index b4d730604972..5e22697b098d 100644\n> --- a/kernel/time/clockevents.c\n> +++ b/kernel/time/clockevents.c\n> @@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct clock_event_device *dev,\n>   \tif (dev->features & CLOCK_EVT_FEAT_DUMMY)\n>   \t\treturn 0;\n>   \n> +\t/* On state transitions clear the forced flag unconditionally */\n> +\tdev->next_event_forced = 0;\n> +\n>   \t/* Transition with new state-specific callbacks */\n>   \tswitch (state) {\n>   \tcase CLOCK_EVT_STATE_DETACHED:\n> @@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires, b\n>   \tif (delta > (int64_t)dev->min_delta_ns) {\n>   \t\tdelta = min(delta, (int64_t) dev->max_delta_ns);\n>   \t\tcycles = ((u64)delta * dev->mult) >> dev->shift;\n> -\t\tif (!dev->set_next_event((unsigned long) cycles, dev))\n> +\t\tif (!dev->set_next_event((unsigned long) cycles, dev)) {\n> +\t\t\tdev->next_event_forced = 0;\n>   \t\t\treturn 0;\n> +\t\t}\n>   \t}\n>   \n>   \tif (dev->next_event_forced)\n> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\n> index 7e57fa31ee26..115e0bf01276 100644\n> --- a/kernel/time/tick-broadcast.c\n> +++ b/kernel/time/tick-broadcast.c\n> @@ -108,6 +108,7 @@ static struct clock_event_device *tick_get_oneshot_wakeup_device(int cpu)\n>   \n>   static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)\n>   {\n> +\twd->next_event_forced = 0;\n>   \t/*\n>   \t * If we woke up early and the tick was reprogrammed in the\n>   \t * meantime then this may be spurious but harmless.\n\nOk, it does fix the problem! Thank you.\nThe patch itself does not apply cleanly for 7.0 though and I had to adapt it a bit.","headers":{"Return-Path":"\n <netfilter-devel+bounces-11893-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=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=CKD8hswe;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.105.105.114; helo=tor.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11893-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=\"CKD8hswe\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=209.85.218.44","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=gmail.com"],"Received":["from tor.lore.kernel.org (tor.lore.kernel.org [172.105.105.114])\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 4fwHdv499fz1y2d\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 07:36:19 +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 4EA4B3072A95\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 14 Apr 2026 21:36:11 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 0A26238656D;\n\tTue, 14 Apr 2026 21:36:07 +0000 (UTC)","from mail-ej1-f44.google.com (mail-ej1-f44.google.com\n [209.85.218.44])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D47038645B\n\tfor <netfilter-devel@vger.kernel.org>; Tue, 14 Apr 2026 21:36:04 +0000 (UTC)","by mail-ej1-f44.google.com with SMTP id\n a640c23a62f3a-b932fe2e1a7so839516766b.1\n        for <netfilter-devel@vger.kernel.org>;\n Tue, 14 Apr 2026 14:36:04 -0700 (PDT)","from 127.0.0.1 ([94.41.86.134])\n        by smtp.gmail.com with ESMTPSA id\n a640c23a62f3a-b9d6de8d709sm449315266b.8.2026.04.14.14.36.00\n        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n        Tue, 14 Apr 2026 14:36:01 -0700 (PDT)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776202566; cv=none;\n b=HGFW4gA2btl41X3yO1i1CA2f4FRnKOKjFO98XxrXUEhkUzK+6gti91ykaxHjbmJuVvr3/90iqDgMDiQwJYifHLAh2EvBLf9scVZvQ6mMAbwe7AsTiMr+CnMPJSAeU16UreMCUZ0eUqf64hwqexxKvizlyMTqzjQIkdm6Y7GlkGI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776202566; c=relaxed/simple;\n\tbh=0TMK6TPj2I/wDCZC3TKkkZR0vWPLJmtivYg0Oosnwbw=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=fhDuFPrgJWIcnNk935cJKJ1D3jL5Tl3QgsrGJZMGSnKEaq5+g2AsqthqNWKN37+hNX7blOtDecX5RC20k25bh6It3tF5tyoSxf56NsV1w+GJL7jTCMlBtKrL2XKWEFYT/ZfOIPzG6g4c60uzYE/BvQam3FEyBtkH0weOhBOz81c=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com;\n spf=pass smtp.mailfrom=gmail.com;\n dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com\n header.b=CKD8hswe; arc=none smtp.client-ip=209.85.218.44","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=gmail.com; s=20251104; t=1776202563; x=1776807363;\n darn=vger.kernel.org;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender:from\n         :to:cc:subject:date:message-id:reply-to;\n        bh=FVfeBwiYFSjucW7g9phomZssZLdfk3en30hBBiRPj+E=;\n        b=CKD8hswejFyJ6d0NueXf5SrY2Yru5vKmq1YraCdrqWMGZ5QF9ZBSbEc279u+bQiLnc\n         kGxpfO9QKdOMSHYcToyrJPtArAGDMKUl4Jo7tsW0PnZMofNm+l6YFrsdugfd6zYx8ssK\n         wb7/b2h6z1kV4DZ/x/TIlQvF1xTsZ0lwXm2blP9MZN4vKJPt2f2aNFylSI0bmuocRudm\n         i1+LXDCBFrMENaozlHJ8G4mSNIwyLscbHRPsUkPzG1xqeY7k9UoKq/KkpdrWF4ZelLMd\n         x+pDvgFcyMF2ACMHFQsVRH8/BU2Ke4C475Fm+7hv97Z6Nxj26rseVMTqCedYMWKGLXjN\n         S4Mg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n        d=1e100.net; s=20251104; t=1776202563; x=1776807363;\n        h=content-transfer-encoding:in-reply-to:from:content-language\n         :references:cc:to:subject:mime-version:date:message-id:sender\n         :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n         :reply-to;\n        bh=FVfeBwiYFSjucW7g9phomZssZLdfk3en30hBBiRPj+E=;\n        b=Tdowba3YgCK0NYSyuSWt7oyD2HFyYTVnhC81Lw5pftgtA9SgH8Feoeq3nHcupDRSdM\n         4k3tmVityTvBmQHkF6PH6OZfFTYJOjRvxg/JJS/5emoc+zM0+03/Al3rLaJM+zajy1QN\n         o+p0N/aEHYQE70cYO3UpM7ZoOcdcrazCa/xRxutWTayMWOzbUlRWSM2KUPpu2slsNFNq\n         9G84j/kuT/jEQobNCtZOKcvNmakQ2LMyGpjCA/S331/cuA8rB8/BcKULAhUNTiwWq0++\n         QV7S6jh6pMoMnTvQOAgL1AW7dk2Xkl07yCW3i+8adZpcSHDECfj+9L6WtI+G7HlPd42Z\n         wZ4w==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8jRluqBTpJGoeH9olPwJIUkhLcVGMUmCZAlxxsz1iaWzujrb67PuA4OXWgUGt/H91hTK3czQannR4fvGvPxaY=@vger.kernel.org","X-Gm-Message-State":"AOJu0Yz8aFNa8c8kAWzRLlasFX8vEMWyuLjmWIwc96nJnqnpjyzmd8vE\n\tYA5jmS3S/WxTtygaBT33/fUI+LE1BuAcFu3Gng0nXSQHy3VasQXSZswU","X-Gm-Gg":"AeBDievffptfMhKCjs9hbuz9t7moAc0nkHCjKjsw2ROB9+A0BEvoo3Zc1utjNbCPYOM\n\tUQvNrevsKcUbDIpHwptj21OMwlDvPBdB13TpEgZYo3Y7C0fNIiHSNSAeLEViFiprxdXpIUbhByk\n\tfi572A8ZNApEnl0MaHq/0dv1s7mlYV5Qp8svIHt/ZMTi8FQEsccPzrHVifPb+OOVnH6M/DPSkJv\n\tomLl+mwB7Nhlmvf+bJZMbaA38wZ7B8xiULu8FcQcxYV/XCm1zb5nbzp+nV0gRkxOg5RQFMQ8JST\n\t0diz7D9pKSoDocyJj6ZIdDF/qiqsBExry82wPvK1JUabMnD3CCLf1XvsvPuPj3qIkczScQ2uBWL\n\tAsAFULEx1uCGyq92y/bAHXYkc5sjLKluH7iiZvP2UFdQ4pCvNJyWJveP+j94AUOrHHed7G76+Bq\n\tHJYCyLlW++KxETGi32W+OFRhTtu9OfETp3bBrmMsDLlZo=","X-Received":"by 2002:a17:906:6a03:b0:b98:48b1:b129 with SMTP id\n a640c23a62f3a-b9d727969e8mr1203629666b.47.1776202563125;\n        Tue, 14 Apr 2026 14:36:03 -0700 (PDT)","Sender":"<irecca.kun@gmail.com>","Message-ID":"<e6d3dc64-1714-4105-8a38-3942c62d159a@gmail.com>","Date":"Tue, 14 Apr 2026 21:35:59 +0000","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","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","To":"Thomas Gleixner <tglx@kernel.org>","Cc":"Frederic Weisbecker <frederic@kernel.org>, Eric Naim <dnaim@cachyos.org>,\n LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Ingo Molnar\n <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n Stephen Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>\n <ad6BtKRj1GyreNCS@localhost.localdomain>\n <a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com> <87340xfeje.ffs@tglx>","Content-Language":"en-US","From":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>","In-Reply-To":"<87340xfeje.ffs@tglx>","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit"}},{"id":3677681,"web_url":"http://patchwork.ozlabs.org/comment/3677681/","msgid":"<349d61ce-6a5c-48c7-a4b8-a554668dc75c@cachyos.org>","list_archive_url":null,"date":"2026-04-15T13:51:00","subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","submitter":{"id":91359,"url":"http://patchwork.ozlabs.org/api/people/91359/","name":"Eric Naim","email":"dnaim@cachyos.org"},"content":"On 4/15/26 5:35 AM, Hanabishi wrote:\n> On 14/04/2026 20:55, Thomas Gleixner wrote:\n>> The one below should cover all possible holes.\n>>\n>> Thanks,\n>>\n>>          tglx\n>> ---\n>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c\n>> index b4d730604972..5e22697b098d 100644\n>> --- a/kernel/time/clockevents.c\n>> +++ b/kernel/time/clockevents.c\n>> @@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct\n>> clock_event_device *dev,\n>>       if (dev->features & CLOCK_EVT_FEAT_DUMMY)\n>>           return 0;\n>>   +    /* On state transitions clear the forced flag unconditionally */\n>> +    dev->next_event_forced = 0;\n>> +\n>>       /* Transition with new state-specific callbacks */\n>>       switch (state) {\n>>       case CLOCK_EVT_STATE_DETACHED:\n>> @@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device\n>> *dev, ktime_t expires, b\n>>       if (delta > (int64_t)dev->min_delta_ns) {\n>>           delta = min(delta, (int64_t) dev->max_delta_ns);\n>>           cycles = ((u64)delta * dev->mult) >> dev->shift;\n>> -        if (!dev->set_next_event((unsigned long) cycles, dev))\n>> +        if (!dev->set_next_event((unsigned long) cycles, dev)) {\n>> +            dev->next_event_forced = 0;\n>>               return 0;\n>> +        }\n>>       }\n>>         if (dev->next_event_forced)\n>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c\n>> index 7e57fa31ee26..115e0bf01276 100644\n>> --- a/kernel/time/tick-broadcast.c\n>> +++ b/kernel/time/tick-broadcast.c\n>> @@ -108,6 +108,7 @@ static struct clock_event_device\n>> *tick_get_oneshot_wakeup_device(int cpu)\n>>     static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)\n>>   {\n>> +    wd->next_event_forced = 0;\n>>       /*\n>>        * If we woke up early and the tick was reprogrammed in the\n>>        * meantime then this may be spurious but harmless.\n> \n> Ok, it does fix the problem! Thank you.\n> The patch itself does not apply cleanly for 7.0 though and I had to adapt it a\n> bit.\n> \n\nSorry for the delay folks! This patch fixes the regression and a user recently\nconfirmed it as well.\n\nFeel free to add:\nTested-by: Eric Naim <dnaim@cachyos.org>","headers":{"Return-Path":"\n <netfilter-devel+bounces-11922-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 secure) header.d=cachyos.org header.i=@cachyos.org header.a=rsa-sha256\n header.s=dkim header.b=ZJLzIIWV;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=104.64.211.4; helo=sin.lore.kernel.org;\n envelope-from=netfilter-devel+bounces-11922-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=\"ZJLzIIWV\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=202.61.224.105","smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=cachyos.org"],"Received":["from sin.lore.kernel.org (sin.lore.kernel.org [104.64.211.4])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fwjHc4Slvz1yCv\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 23:51:56 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sin.lore.kernel.org (Postfix) with ESMTP id 67D703015FFD\n\tfor <incoming@patchwork.ozlabs.org>; Wed, 15 Apr 2026 13:51:53 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 790363CF66C;\n\tWed, 15 Apr 2026 13:51:51 +0000 (UTC)","from mail.ptr1337.dev (mail.ptr1337.dev [202.61.224.105])\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 997333B3BFE;\n\tWed, 15 Apr 2026 13:51:47 +0000 (UTC)","from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon)\n with ESMTPSA id 83D792860DF;\n\tWed, 15 Apr 2026 15:51:23 +0200 (CEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1776261110; cv=none;\n b=DzkLmglOeZxReDPa9typrsiE2aT2CsFWpUI5nRNAtfclT1NU2yfqnMfiZpbrZmg91MPqawenDzIdTfL1uOwOQITN8r2h1h+TAA/e41+h1UF9dg1iMITa9mZ75ejgN70j/CWhK4LK3cpTJD3pkwWZ7t4MTtjRrqXswIT7nVk8Z48=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1776261110; c=relaxed/simple;\n\tbh=1KQV6DqB3E46shdSQ8zoRrX9PH4TABhATC7C3sT0pOY=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=jMBMgdGx54++fQKTUyunWNp3vLX049IScpbQicnEdm1ggUbnTjL3RvIX2nfThhn3a/Ryjz1HcnYnc0UqwM0eBpPIlkXxoH1w2+d2tVANi79lvqp1JQ+lKv2vrTISOSGTdiKCuVCNAF3/bcHVCEx+gNf9P2//b2HoNly8sF47bU0=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=quarantine dis=none) header.from=cachyos.org;\n spf=pass smtp.mailfrom=cachyos.org;\n dkim=pass (2048-bit key) header.d=cachyos.org header.i=@cachyos.org\n header.b=ZJLzIIWV; arc=none smtp.client-ip=202.61.224.105","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=cachyos.org; s=dkim;\n\tt=1776261104; h=from:subject:date:message-id:to:cc:mime-version:content-type:\n\t content-transfer-encoding:in-reply-to:references;\n\tbh=cjL+4kTqmR79x407tHHUuU7PJnejCHLxK2FDjGKVSkg=;\n\tb=ZJLzIIWVGcccF460uwPK3yiv8WlgQ2kV8g+Pp4QaZhFeDltUkgkX+yc8Mf5XKdPWl9FFbj\n\tjkDoyDYvxyx8zZuQFYTkg8K2TmgwQURGjqpkoIBVNi9fMG120oQWQLpRZ3z8Z+g6uY1PXF\n\tz3+XdjZjKvnshBsdEPJhzEO23rqiocg6eslY/9cO22tQptYtlA+Nb/g07B+UP7VZit6N2E\n\tbn9QwiEySVtXoP28L3LhDLz28qVpm8otqykreJCfMkm9iGI7HB8OpAggnkkaEv5VL9aIpz\n\t96c660bV36WKO5f+tH++CXBjIAnMwqDDQpmJ1MigVVl0IcQUWlSS76hwCy+DoA==","Message-ID":"<349d61ce-6a5c-48c7-a4b8-a554668dc75c@cachyos.org>","Date":"Wed, 15 Apr 2026 13:51:00 +0000","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","Subject":"Re: The \"clockevents: Prevent timer interrupt starvation\" patch\n causes lockups","To":"Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com>,\n Thomas Gleixner <tglx@kernel.org>","Cc":"Frederic Weisbecker <frederic@kernel.org>,\n LKML <linux-kernel@vger.kernel.org>, Calvin Owens <calvin@wbinvd.org>,\n Peter Zijlstra <peterz@infradead.org>,\n Anna-Maria Behnsen <anna-maria@linutronix.de>, Ingo Molnar\n <mingo@kernel.org>, John Stultz <jstultz@google.com>,\n Stephen Boyd <sboyd@kernel.org>, Alexander Viro <viro@zeniv.linux.org.uk>,\n Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,\n linux-fsdevel@vger.kernel.org, Sebastian Reichel <sre@kernel.org>,\n linux-pm@vger.kernel.org, Pablo Neira Ayuso <pablo@netfilter.org>,\n Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,\n netfilter-devel@vger.kernel.org, coreteam@netfilter.org","References":"<20260407083219.478203185@kernel.org>\n <20260407083247.562657657@kernel.org>\n <68d1e9ac-2780-4be3-8ee3-0788062dd3a4@gmail.com>\n <aeb848aa-404a-40fb-bd41-329644623b1d@cachyos.org>\n <ad6BtKRj1GyreNCS@localhost.localdomain>\n <a3ac856c-914c-4b39-949f-634bed501e7c@gmail.com> <87340xfeje.ffs@tglx>\n <e6d3dc64-1714-4105-8a38-3942c62d159a@gmail.com>","From":"Eric Naim <dnaim@cachyos.org>","In-Reply-To":"<e6d3dc64-1714-4105-8a38-3942c62d159a@gmail.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-Last-TLS-Session-Version":"TLSv1.3"}}]