linux-kernel - Re: [RFC] irq: Skip printing irq when desc->action is null even if any

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87k15jek6v.fsf@nanos.tec.linutronix.de>
Date:   Wed, 22 Jan 2020 13:42:48 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     l00520965 <liuchao173@...wei.com>
Cc:     linfeilong@...wei.com, hushiyuan@...wei.com,
        LiuChao <liuchao173@...wei.com>, linux-kernel@...r.kernel.org,
        PJ Waskiewicz <peter.waskiewicz.jr@...el.com>,
        Neil Horman <nhorman@...driver.com>
Subject: Re: [RFC] irq: Skip printing irq when desc->action is null even if any_count is not zero

Chao,

l00520965 <liuchao173@...wei.com> writes:

> When desc->action is empty, there is no need to print out the irq and its'
> count in each cpu. The desc is not alloced in request_irq or freed in
> free_irq.

request/free_irq() never allocate/free irq descriptors. 

> So some PCI devices, such as rtl8139, uses request_irq and free_irq,

All PCI devices use some variant of request_irq()/free_irq(). The
interrupt descriptors are allocated by the underlying PCI
machinery. They are only allocated/freed when the device driver is
loaded/removed.

And this property exists for _ALL_ interrupts independent of PCI.

> which only modify the action of desc. So /proc/interrupts could be
> like this:

I think you want to explain:

  If an interrupt is released via free_irq() without removing the
  underlying irq descriptor, the interrupt count of the irq descriptor
  is not reset. /proc/interrupt shows such interrupts with an empty
  action handler name:

>            CPU0       CPU1
>  38:         46          0     GICv3  36 Level     ehci_hcd:usb1
>  39:         66          0     GICv3  37 Level

  irqbalance fails to detect that this interrupt is not longer in use
  and parses the last word in the line 'Level' as the action handler
  name.

> Irqbalance gets the list of interrupts according to /proc/interrupts. In
> this case, irqbalance does not remove the interrupt from the balance list,
> and the last string in this line,which is Level, is used as irq_name.

Right, this is historic behaviour and I don't know how irqbalance dealt
with that in the past 20+ years. At least I haven't seen any complaints.

I'm not opposed to suppress the output, but I really want the opinion of
the irqbalance maintainers on that.

> Or we can clear desc->kstat_irqs in each cpu in free_irq when
> desc->action is null?

No, we can't. The historic behaviour is that the total interrupt count
for a device is maintained independent of the number of
request/free_irq() pairs.

> Signed-off-by: LiuChao <liuchao173@...wei.com>
> Reviewed-by: Thomas Gleixner <tglx@...utronix.de>

I really can't remember that I have reviewed this patch already. Please
don't add tags which claim that some one has reviewed or acked your
patch unless you really got that Reviewed-by or Acked-by from that
person.

Thanks,

        tglx