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: <2f41d622f1f9e41026e93c2dc18aa65b@kernel.org>
Date:   Sat, 27 Jun 2020 12:42:52 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Valentin Schneider <valentin.schneider@....com>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@....linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        Sumit Garg <sumit.garg@...aro.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Andrew Lunn <andrew@...n.ch>, kernel-team@...roid.com
Subject: Re: [PATCH v2 15/17] arm64: Remove custom IRQ stat accounting

On 2020-06-27 00:15, Valentin Schneider wrote:
> On 26/06/20 12:58, Marc Zyngier wrote:
>> On 2020-06-25 19:26, Valentin Schneider wrote:
>>> On 24/06/20 20:58, Marc Zyngier wrote:
>>>> @@ -801,26 +802,15 @@ void show_ipi_list(struct seq_file *p, int 
>>>> prec)
>>>>       unsigned int cpu, i;
>>>> 
>>>>       for (i = 0; i < NR_IPI; i++) {
>>>> +		unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
>>>>               seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
>>>>                          prec >= 4 ? " " : "");
>>>>               for_each_online_cpu(cpu)
>>>> -			seq_printf(p, "%10u ",
>>>> -				   __get_irq_stat(cpu, ipi_irqs[i]));
>>>> +			seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu));
>>>>               seq_printf(p, "      %s\n", ipi_types[i]);
>>> 
>>> How attached are we to that custom IPI printout? AIUI we *could* give
>>> them
>>> a "prettier" name in request_percpu_irq() and let the standard procfs
>>> printout take the wheel.
>> 
>> I wish. Unfortunately, /proc/interrupts is likely to be considered 
>> ABI,
>> and I'm really worried to change this (see what happened last time we
>> tried to update /proc/cpuinfo to be less braindead...).
>> 
> 
> Hmph, it's borderline here I think: we're not introducing a new field 
> or
> format in the file, so any tool that can parse /proc/interrupts can 
> parse
> the IPIs if they are formatted like the other "regular" interrupts. But
> then said tool could die in flames when not seeing the special IPI 
> fields
> because sturdiness is overrated :(

Which is exactly what I'm worried about. People do stupid things,
and stupidity becomes ABI. I hate luserspace.

          M.
-- 
Jazz is not dead. It just smells funny...

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ