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: <87pnfatkpy.fsf@nanos.tec.linutronix.de>
Date:   Thu, 23 Jan 2020 13:34:33 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "liuchao \(CR\)" <liuchao173@...wei.com>,
        Neil Horman <nhorman@...driver.com>
Cc:     linfeilong <linfeilong@...wei.com>,
        Hushiyuan <hushiyuan@...wei.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: 答复: [RFC] irq: Skip printing irq when
 desc->action is null even if any_count is not zero

Chao,

"liuchao (CR)" <liuchao173@...wei.com> writes:
> On Thu, Jan 23, 2020 at 03:29AM +0800, Neil Horman wrote:
>> > I'm not opposed to suppress the output, but I really want the opinion
>> > of the irqbalance maintainers on that.
>
> Irqbalance is an example. I mean, when this happens, users who cat /proc/interrupts 
> may be confused about where the interrupt came from and what it was used for. 
> People who use Linux may not understand the principle of this. They are not sure 
> whether this is a problem of the system or not.

Well, this has been that way for 20+ years and so far nobody got
confused. If it's not documented then we should do so.

>> Actually, irqbalance ignores the trailing irq name (or it should at least), so you
>> should be able to drop that portion of /proc/irqbalance, though I cant speak for
>> any other users of it.
>
> If irq isn't removed from /proc/interrups, it will still be parsed in
> collect_full_irq_list and parse_proc_interrupts.

Sure, and why is that a problem? Again, this is really historic behaviour.

> irq_name is used in guess_arm_irq_hints.

That's a problem of guess_arm_irq_hints() then.

Again, I'm not against supressing such lines in general, but I want to
make sure that no tool depends on that information.

Thanks,

        tglx