[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y2ia7rbv.fsf@nanos.tec.linutronix.de>
Date: Sun, 06 Dec 2020 18:54:44 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Jerry Snitselaar <jsnitsel@...hat.com>,
linux-kernel@...r.kernel.org
Cc: linux-integrity@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, kernel test robot <lkp@...el.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Jason Gunthorpe <jgg@...pe.ca>,
Peter Huewe <peterhuewe@....de>,
James Bottomley <James.Bottomley@...senPartnership.com>,
Matthew Garrett <mjg59@...gle.com>,
Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v3 1/4] irq: export kstat_irqs
Jerry,
On Fri, Dec 04 2020 at 18:43, Jerry Snitselaar wrote:
The proper prefix is 'genirq:' git log kernel/irq/irqdesc.c would have
told you.
> To try and detect potential interrupt storms that
> have been occurring with tpm_tis devices it was suggested
> to use kstat_irqs() to get the number of interrupts.
> Since tpm_tis can be built as a module it needs kstat_irqs
> exported.
I'm not really enthused about exporting this without making it at least
safe. Using it from an interrupt handler is obviously safe vs. concurrent
removal, but the next driver writer who thinks this is cool is going to
get it wrong for sure.
Though I still have to figure out what the advantage of invoking a
function which needs to do a radix tree lookup over a device local
counter is just to keep track of this.
I'll reply on the TPM part of this as well.
Thanks,
tglx
Powered by blists - more mailing lists