linux-kernel - Re: [PATCHv5 2/3] watchdog/softlockup: report the most frequent interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD=FV=XVxaBGWa8apqyhd2KAPFtF7asmPuXvHhv++oj+oKLNsQ@mail.gmail.com>
Date: Wed, 7 Feb 2024 09:14:33 -0800
From: Doug Anderson <dianders@...omium.org>
To: Bitao Hu <yaoma@...ux.alibaba.com>
Cc: akpm@...ux-foundation.org, pmladek@...e.com, kernelfans@...il.com, 
	liusong@...ux.alibaba.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv5 2/3] watchdog/softlockup: report the most frequent interrupts

Hi,

On Tue, Feb 6, 2024 at 10:19 PM Bitao Hu <yaoma@...ux.alibaba.com> wrote:
>
> Hi,
>
> >> +static void start_counting_irqs(void)
> >> +{
> >> +       int i;
> >> +       struct irq_desc *desc;
> >> +       u32 *counts = __this_cpu_read(hardirq_counts);
> >> +       int cpu = smp_processor_id();
> >> +
> >> +       if (!test_bit(cpu, softlockup_hardirq_cpus)) {
> >
> > I don't think you need "softlockup_hardirq_cpus", do you? Just read
> > "actual_nr_irqs" and see if it's non-zero? ...or read "hardirq_counts"
> > and see if it's non-NULL?
> Sure, the existing variables are sufficient for making a determination.
> And may be I should swap it to make the decision logic here clearer,
> like this (untested)?
>
> bool is_counting_started(void)
> {
>      return !!__this_cpu_read(hardirq_counts);
> }
>
> if (!is_counting_started()) {

If you insist I guess I wouldn't object, but I don't feel it's
necessary. The whole point is just to know if you've already allocated
memory, right? ...and just checking to see if the pointer is non-NULL
or the array-size is non-zero feels pretty clear to me.


> >> +                       /*
> >> +                        * We need to bounds-check in case someone on a different CPU
> >> +                        * expanded nr_irqs.
> >> +                        */
> >> +                       if (i < __this_cpu_read(actual_nr_irqs))
> >> +                               counts_diff = desc->kstat_irqs ?
> >> +                                       *this_cpu_ptr(desc->kstat_irqs) - counts[i] : 0;
> >> +                       else
> >> +                               counts_diff = desc->kstat_irqs ?
> >> +                                       *this_cpu_ptr(desc->kstat_irqs) : 0;
> >
> > Why do you need to test "kstat_irqs" for 0?
> Although "alloc_desc" wil allocate both "desc" and "kstat_irqs" at the
> same time, I refer to the usage of "kstat_irqs" in "show_interrupts"
> from kernel/irq/proc.c, where it does perform a check.

Ah, I see. I hadn't noticed that you were testing the pointer before
dereferencing it. OK, seems fine to keep this check. I guess that
would make it this (untested):

if (desc->kstat_irqs) {
  counts_diff = *this_cpu_ptr(desc->kstat_irqs);
  if (i < __this_cpu_read(actual_nr_irqs))
    counts_diff -= counts[i];
} else {
  counts_diff = 0;
}