Received-SPF: pass (google.com: domain of linux-kernel+bounces-58322-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240208125426.70511-1-yaoma@linux.alibaba.com> <20240208125426.70511-3-yaoma@linux.alibaba.com>
In-Reply-To: <20240208125426.70511-3-yaoma@linux.alibaba.com>
From: Doug Anderson <dianders@chromium.org>
Date: Thu, 8 Feb 2024 08:03:50 -0800
Message-ID: <CAD=FV=UP_G3Rswi_HePkgmcniADKhkoP51=H=PxGKbdegEfUgg@mail.gmail.com>
Subject: Re: [PATCHv6 2/2] watchdog/softlockup: report the most frequent interrupts
To: Bitao Hu <yaoma@linux.alibaba.com>
Cc: akpm@linux-foundation.org, pmladek@suse.com, kernelfans@gmail.com, 
	liusong@linux.alibaba.com, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Feb 8, 2024 at 4:54=E2=80=AFAM Bitao Hu <yaoma@linux.alibaba.com> w=
rote:
>
> +static void start_counting_irqs(void)
> +{
> +       int i;
> +       int local_nr_irqs;
> +       struct irq_desc *desc;
> +       u32 *counts =3D __this_cpu_read(hardirq_counts);
> +
> +       if (!counts) {
> +               /*
> +                * nr_irqs has the potential to grow at runtime. We shoul=
d read
> +                * it and store locally to avoid array out-of-bounds acce=
ss.
> +                */
> +               local_nr_irqs =3D READ_ONCE(nr_irqs);

nit: I don't think the READ_ONCE() is actually needed above. All that
matters is that you're consistently using the same local variable
("local_nr_irqs") for allocating the array, looping, and then storing.
No matter what optimizations might be happening and what else might be
happening on other CPUs, once you put it in a local variable the
compiler _must_ keep it consistent.

That being said, I don't think it really matters, so I'm not sure it's
worth spinning your series just for that.

In any case, this patch looks good to me now. Thanks!

Reviewed-by: Douglas Anderson <dianders@chromium.org>