[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lfeahakt.fsf@redhat.com>
Date: Sun, 06 Dec 2020 14:46:26 -0700
From: Jerry Snitselaar <jsnitsel@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, 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
Thomas Gleixner @ 2020-12-06 10:54 MST:
> 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
I can rework it to use a device local counter.
Powered by blists - more mailing lists