linux-kernel - Re: [PATCH v3] genirq: Machine-parsable version of /proc/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] [thread-next>] [day] [month] [year] [list]

Message-ID: <bac9d45e-8978-be16-b9a6-ba6cb5a6b6f0@infradead.org>
Date:   Thu, 8 Sep 2016 15:00:50 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Craig Gallek <kraigatgoog@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     David Decotigny <decot@...gle.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] genirq: Machine-parsable version of /proc/interrupts

On 09/08/16 13:25, Craig Gallek wrote:
> From: Craig Gallek <kraig@...gle.com>
> 
> Add struct kobject to struct irq_desc to allow for easy export
> to sysfs.  This allows for much simpler userspace-parsing of
> the information contained in struct irq_desc.
> 
> Note that sysfs is not available at the time of early irq initialization.
> These interrupts are accounted for using a postcore_initcall callback.
> 
> Examples:
>   /sys/kernel/irq/18/actions:	i801_smbus,ehci_hcd:usb1,uhci_hcd:usb7
>   /sys/kernel/irq/18/chip_name:	IR-IO-APIC
>   /sys/kernel/irq/18/hwirq:		18
>   /sys/kernel/irq/18/name:		fasteoi
>   /sys/kernel/irq/18/per_cpu_count:	0,0
>   /sys/kernel/irq/18/type:		level
> 
>   /sys/kernel/irq/25/actions:	ahci0
>   /sys/kernel/irq/25/chip_name:	IR-PCI-MSI
>   /sys/kernel/irq/25/hwirq:		512000
>   /sys/kernel/irq/25/name:		edge
>   /sys/kernel/irq/25/per_cpu_count:	29036,0
>   /sys/kernel/irq/25/type:		edge

Thanks for the update.

One concern:

This per_cpu_count is for online CPUs only.
How does this help when the online CPUs change?

E.g., above could be for CPUs 1 and 5.
The next time that it is read it could be for CPUs 0 and 3.
Seems that it could be confusing even for software reading it.


-- 
~Randy