From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4AB25212F98 for ; Wed, 28 Jan 2026 18:13:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769624020; cv=none; b=f3DYyTWgV0U8648uYjO03qUNVc7MmPYWRnfOLNHLBnGOwm2A+3aGDL/qsj4IQ6wdgNS2GINXxah/arLt7AoPzEPtI9ktaAA6zFCoBvmdo1Hl/ihKIO6D0Nucec7ZVZRmbVHIm6XzJ1GzRhM0MEcPai3P3k3OpCvWIT1EwsX5b1o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769624020; c=relaxed/simple; bh=p/66I4QdIrtUS9i3HRvRkj7D7Jy/cY2usvKAZt+Ebdc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=HppU2s+l8Klsmp+a8onfno2wkkZNCqF4j3jivCU+PwtEbcHaq8mT/0JotkmonG3Q8Ke2WTKSwUD1oo2bHKqnRoeB9+Q6ERzqqtKmrhDXKNIypIWpMTfDrtcRUj8ETwcC3++bObNA3fmoCwahbXhinH6Rjz4FjLoPfH7UrKz05bQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=epKWBnfr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="epKWBnfr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C4ADC4CEF1; Wed, 28 Jan 2026 18:13:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1769624019; bh=p/66I4QdIrtUS9i3HRvRkj7D7Jy/cY2usvKAZt+Ebdc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=epKWBnfr8+aw2l3aRZB+H7bCOLMBoHxUQhz1SAWONNKctORe3nj3FzDPmiA3hfHgx zSKGkFUD2wcLLhuM2BdLEG7/HpsPP1jd1w/dgFaLfYdPR4DSMrboKOxuvm3auv1C0F uL6kuUd8ra1e1oEdnZr1M388nlDzbywAypGmJn5E= Date: Wed, 28 Jan 2026 10:13:39 -0800 From: Andrew Morton To: Petr Mladek Cc: shengminghu512 , tglx , mingo , broonie , linux-kernel , "hu.shengming" , "zhang.run" Subject: Re: [PATCH] watchdog/softlockup: Fix sample ring index wrap in need_counting_irqs() Message-Id: <20260128101339.658d522c69bb4466218ee437@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 28 Jan 2026 18:52:11 +0100 Petr Mladek wrote: > On Mon 2026-01-19 21:59:05, shengminghu512 wrote: > > From: Shengming Hu > > > > cpustat_tail indexes cpustat_util[], which is a NUM_SAMPLE_PERIODS-sized > > ring buffer. need_counting_irqs() currently wraps the index using > > NUM_HARDIRQ_REPORT, which only happens to match NUM_SAMPLE_PERIODS. > > > > Use NUM_SAMPLE_PERIODS for the wrap to keep the ring math correct even if > > the NUM_HARDIRQ_REPORT or NUM_SAMPLE_PERIODS changes. > > > > --- > > kernel/watchdog.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/watchdog.c b/kernel/watchdog.c > > index b4d5fbdb9..7d675781b 100644 > > --- a/kernel/watchdog.c > > +++ b/kernel/watchdog.c > > @@ -550,7 +550,7 @@ static bool need_counting_irqs(void) > > u8 util; > > int tail = __this_cpu_read(cpustat_tail); > > > > - tail = (tail + NUM_HARDIRQ_REPORT - 1) % NUM_HARDIRQ_REPORT; > > + tail = (tail + NUM_SAMPLE_PERIODS - 1) % NUM_SAMPLE_PERIODS; > > util = __this_cpu_read(cpustat_util[tail][STATS_HARDIRQ]); > > return util > HARDIRQ_PERCENT_THRESH; > > Great catch! It makes perfect sense. > > The NUM_HARDIRQ_REPORT is used for another array (irq_counts_sorted[]) > with the most frequent IRQs. This code was added with the same commit > which added the other array. It would explain the mistake. > > Reviewed-by: Petr Mladek Fixes: e9a9292e2368 ("watchdog/softlockup: Report the most frequent interrupts"), yes? What are the runtime effects of this? "most frequent interrupts" data is messed up? I'm assuming we want to fix earlier kernels, so cc:stable? > Andrew, I assume that you would take it... Sure, I can queue it. e9a9292e2368 was merged by tglx so he might want to take it - if so I'll drop the mm.git copy if/when this appears in linux-next.