From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9777823909F for ; Sun, 5 Jul 2026 10:13:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783246412; cv=none; b=J7z0kADVlf1tYbBalYMkzI5/HE8Zx412g8DKVuDfs1Uv4PsRTCb0eak0diEnx4BNY4GuENJnRgFm09aHELFC0mJHtCq9JjUIBH0N/uvgQHEocKQG6kPkYpQw6NDApvhRu8x4qhBRLHjxaREZZk+pz4W/kfMvihIL/SMIrCC6NpM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783246412; c=relaxed/simple; bh=UHe8Fq4JOVaqDCMfg1Cy9NXy5WE816bXH4jcXIO6mPk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oS0iMR7QT0zH8JJJvtzvT+RFlLQpkQhs4iyHA+Kwhx7fWQdfhkSEnydLWbX2AQBvEnlqxdL7Ki5q8HLljrLp9E2T56iep45qYB/SEbNn1RwRfmjz126tLEH5xxVEH6V2Y47kc2nGCrbj04wubXK7feMCCiV9kn7UUX5F4sv+L4E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OAlSN1Qk; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OAlSN1Qk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A41F21F000E9; Sun, 5 Jul 2026 10:13:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783246411; bh=I6AgsKszYJPEHXmyUZTF2sSfRU1M6xL6eC9ZW9QZE9U=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=OAlSN1QkVAtvk03m+L/0bnJIwa3B8Mvbd21F64dgL+uKHlzWaikJKNS/xzcFdPS5I EBLBNykRX7cODko8uqzk5lsCsr8uDbgOEG0sr9sqd/XQdHf7myhVTzkABS9PG7XmQD SLuVB8U+4RX3TjGjYXRJCeisNWDx0ZEQHh38U3D3gC47z2fP5mmX48vzjVHab+p9Qc 5ZlERLcMBrdZrdvdgfdjmR+sEdz59DLd2JDubgnoZFqjXh7PrJ4oyTZ6+qhhVy4Rbh EBJ9SrTozOfM6mFsGD7D0u3AAJubJ54SwdoBrZ02WuxkMYUas9N6ZCy2xOyBa4F5E1 o/nD1o4PWv4EQ== From: Thomas Gleixner To: tanze , anna-maria@linutronix.de, frederic@kernel.org Cc: linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH v1] timers: Feed soft lockup watchdog in expire_timers() In-Reply-To: <20260703083624.80072-1-tanze@kylinos.cn> References: <20260703083624.80072-1-tanze@kylinos.cn> Date: Sun, 05 Jul 2026 12:13:28 +0200 Message-ID: <87zf05kalz.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Jul 03 2026 at 16:36, tanze@kylinos.cn wrote: Thanks for your patch. First of all, you have to provide your real name for signing off on a patch. Your nickname does not cut it. See Documentation/process. > expire_timers() iterates over all expired timers and invokes their > callbacks one by one in softirq context. Each individual callback may > complete quickly, but when a very large number of timers expire at the > same tick, the aggregate time spent in this loop can exceed the soft > lockup watchdog threshold, causing a false positive: No. It's not a false positive. > This is reproducible by issuing many perf_event_open() syscalls with > PERF_COUNT_SW_CPU_CLOCK and a very small sample_period, which creates > a large number of software timers that expire simultaneously. The CPU > is making forward progress -- executing timer callbacks one after > another -- but the watchdog is never reset during the batch. Found by > running syzkaller on a local QEMU instance. The watchdog validates that the CPU is making forward progress for tasks. Spending 26 seconds in soft interrupt handling does therefore not qualify. > Add touch_softlockup_watchdog() after each call_timer_fn() invocation > in expire_timers(). This resets the watchdog timestamp after every > successfully completed callback. Which papers over the underlying problem. > @@ -1792,11 +1793,13 @@ static void expire_timers(struct timer_base *base, struct hlist_head *head) > if (timer->flags & TIMER_IRQSAFE) { > raw_spin_unlock(&base->lock); > call_timer_fn(timer, fn, baseclk); > + touch_softlockup_watchdog(); > raw_spin_lock(&base->lock); > base->running_timer = NULL; > } else { > raw_spin_unlock_irq(&base->lock); > call_timer_fn(timer, fn, baseclk); > + touch_softlockup_watchdog(); > raw_spin_lock_irq(&base->lock); > base->running_timer = NULL; > timer_sync_wait_running(base); PERF_COUNT_SW_CPU_CLOCK does not even use timer list timers, so how is expire_timers() even involved? Thanks, tglx