All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Peter Huewe <peterhuewe@gmx.de>,
	Matthew Garrett <mjg59@google.com>,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
Date: Tue, 8 Dec 2020 19:43:44 +0200	[thread overview]
Message-ID: <20201208174344.GC58213@kernel.org> (raw)
In-Reply-To: <db6ccb14819c4c7a32e886eade144884fafc55fe.camel@HansenPartnership.com>

On Mon, Dec 07, 2020 at 11:58:44AM -0800, James Bottomley wrote:
> On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > > and that function is leaking the interrupt request if any of the
> > > checks afterwards fails, except for the final interrupt probe check
> > > which does a cleanup. That means on fail before that the interrupt
> > > handler stays requested up to the point where the module is
> > > removed. If that's a shared interrupt and some other device is
> > > active on the same line, then each interrupt from that device will
> > > call into the TPM code. Something like the below is needed.
> > > 
> > > Also the X86 autoprobe mechanism is interesting:
> > > 
> > > 	if (IS_ENABLED(CONFIG_X86))
> > > 		for (i = 3; i <= 15; i++)
> > > 			if (!tpm_tis_probe_irq_single(chip, intmask, 0,
> > > i))
> > > 				return;
> > > 
> > > The third argument is 'flags' which is handed to request_irq(). So
> > > that won't ever be able to probe a shared interrupt. But if an
> > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt
> > > is requested with IRQF_SHARED. Same issue when the chip has an
> > > interrupt number in the register. It's also requested exclusive
> > > which is pretty likely to fail on ancient x86 machines.
> > 
> > It is very likely none of this works any more, it has been repeatedly
> > reworked over the years and just left behind out of fear someone
> > needs it. I've thought it should be deleted for a while now.
> > 
> > I suppose the original logic was to try and probe without SHARED
> > because a probe would need exclusive access to the interrupt to tell
> > if the TPM was actually the source, not some other device.
> > 
> > It is all very old and very out of step with current thinking, IMHO.
> > I skeptical that TPM interrupts were ever valuable enough to deserve
> > this in the first place.
> 
> For what it's worth, I agree.  Trying to probe all 15 ISA interrupts is
> last millennium thinking we should completely avoid.  If it's not
> described in ACPI then you don't get an interrupt full stop.
> 
> James

Maybe you could add this as part of your patches?

/Jarkko

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
	intel-gfx@lists.freedesktop.org,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Matthew Garrett <mjg59@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-integrity@vger.kernel.org, Peter Huewe <peterhuewe@gmx.de>
Subject: Re: [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
Date: Tue, 8 Dec 2020 19:43:44 +0200	[thread overview]
Message-ID: <20201208174344.GC58213@kernel.org> (raw)
In-Reply-To: <db6ccb14819c4c7a32e886eade144884fafc55fe.camel@HansenPartnership.com>

On Mon, Dec 07, 2020 at 11:58:44AM -0800, James Bottomley wrote:
> On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > > and that function is leaking the interrupt request if any of the
> > > checks afterwards fails, except for the final interrupt probe check
> > > which does a cleanup. That means on fail before that the interrupt
> > > handler stays requested up to the point where the module is
> > > removed. If that's a shared interrupt and some other device is
> > > active on the same line, then each interrupt from that device will
> > > call into the TPM code. Something like the below is needed.
> > > 
> > > Also the X86 autoprobe mechanism is interesting:
> > > 
> > > 	if (IS_ENABLED(CONFIG_X86))
> > > 		for (i = 3; i <= 15; i++)
> > > 			if (!tpm_tis_probe_irq_single(chip, intmask, 0,
> > > i))
> > > 				return;
> > > 
> > > The third argument is 'flags' which is handed to request_irq(). So
> > > that won't ever be able to probe a shared interrupt. But if an
> > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt
> > > is requested with IRQF_SHARED. Same issue when the chip has an
> > > interrupt number in the register. It's also requested exclusive
> > > which is pretty likely to fail on ancient x86 machines.
> > 
> > It is very likely none of this works any more, it has been repeatedly
> > reworked over the years and just left behind out of fear someone
> > needs it. I've thought it should be deleted for a while now.
> > 
> > I suppose the original logic was to try and probe without SHARED
> > because a probe would need exclusive access to the interrupt to tell
> > if the TPM was actually the source, not some other device.
> > 
> > It is all very old and very out of step with current thinking, IMHO.
> > I skeptical that TPM interrupts were ever valuable enough to deserve
> > this in the first place.
> 
> For what it's worth, I agree.  Trying to probe all 15 ISA interrupts is
> last millennium thinking we should completely avoid.  If it's not
> described in ACPI then you don't get an interrupt full stop.
> 
> James

Maybe you could add this as part of your patches?

/Jarkko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko@kernel.org>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: intel-gfx@lists.freedesktop.org,
	Jerry Snitselaar <jsnitsel@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Matthew Garrett <mjg59@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-integrity@vger.kernel.org, Peter Huewe <peterhuewe@gmx.de>
Subject: Re: [Intel-gfx] [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected
Date: Tue, 8 Dec 2020 19:43:44 +0200	[thread overview]
Message-ID: <20201208174344.GC58213@kernel.org> (raw)
In-Reply-To: <db6ccb14819c4c7a32e886eade144884fafc55fe.camel@HansenPartnership.com>

On Mon, Dec 07, 2020 at 11:58:44AM -0800, James Bottomley wrote:
> On Mon, 2020-12-07 at 15:28 -0400, Jason Gunthorpe wrote:
> > On Sun, Dec 06, 2020 at 08:26:16PM +0100, Thomas Gleixner wrote:
> > > Just as a side note. I was looking at tpm_tis_probe_irq_single()
> > > and that function is leaking the interrupt request if any of the
> > > checks afterwards fails, except for the final interrupt probe check
> > > which does a cleanup. That means on fail before that the interrupt
> > > handler stays requested up to the point where the module is
> > > removed. If that's a shared interrupt and some other device is
> > > active on the same line, then each interrupt from that device will
> > > call into the TPM code. Something like the below is needed.
> > > 
> > > Also the X86 autoprobe mechanism is interesting:
> > > 
> > > 	if (IS_ENABLED(CONFIG_X86))
> > > 		for (i = 3; i <= 15; i++)
> > > 			if (!tpm_tis_probe_irq_single(chip, intmask, 0,
> > > i))
> > > 				return;
> > > 
> > > The third argument is 'flags' which is handed to request_irq(). So
> > > that won't ever be able to probe a shared interrupt. But if an
> > > interrupt number > 0 is handed to tpm_tis_core_init() the interrupt
> > > is requested with IRQF_SHARED. Same issue when the chip has an
> > > interrupt number in the register. It's also requested exclusive
> > > which is pretty likely to fail on ancient x86 machines.
> > 
> > It is very likely none of this works any more, it has been repeatedly
> > reworked over the years and just left behind out of fear someone
> > needs it. I've thought it should be deleted for a while now.
> > 
> > I suppose the original logic was to try and probe without SHARED
> > because a probe would need exclusive access to the interrupt to tell
> > if the TPM was actually the source, not some other device.
> > 
> > It is all very old and very out of step with current thinking, IMHO.
> > I skeptical that TPM interrupts were ever valuable enough to deserve
> > this in the first place.
> 
> For what it's worth, I agree.  Trying to probe all 15 ISA interrupts is
> last millennium thinking we should completely avoid.  If it's not
> described in ACPI then you don't get an interrupt full stop.
> 
> James

Maybe you could add this as part of your patches?

/Jarkko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-12-08 17:44 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-05  1:43 [PATCH v3 0/4] tpm_tis: Detect interrupt storms Jerry Snitselaar
2020-12-05  1:43 ` [Intel-gfx] " Jerry Snitselaar
2020-12-05  1:43 ` Jerry Snitselaar
2020-12-05  1:43 ` [PATCH v3 1/4] irq: export kstat_irqs Jerry Snitselaar
2020-12-05  1:43   ` [Intel-gfx] " Jerry Snitselaar
2020-12-05  1:43   ` Jerry Snitselaar
2020-12-05 10:39   ` Jarkko Sakkinen
2020-12-05 10:39     ` [Intel-gfx] " Jarkko Sakkinen
2020-12-05 10:39     ` Jarkko Sakkinen
2020-12-06 16:40     ` Thomas Gleixner
2020-12-06 16:40       ` [Intel-gfx] " Thomas Gleixner
2020-12-06 16:40       ` Thomas Gleixner
2020-12-06 17:40       ` James Bottomley
2020-12-06 17:40         ` [Intel-gfx] " James Bottomley
2020-12-06 17:40         ` James Bottomley
2020-12-06 19:29         ` Thomas Gleixner
2020-12-06 19:29           ` [Intel-gfx] " Thomas Gleixner
2020-12-06 19:29           ` Thomas Gleixner
2020-12-06 17:54   ` Thomas Gleixner
2020-12-06 17:54     ` [Intel-gfx] " Thomas Gleixner
2020-12-06 17:54     ` Thomas Gleixner
2020-12-06 21:46     ` Jerry Snitselaar
2020-12-06 21:46       ` [Intel-gfx] " Jerry Snitselaar
2020-12-06 21:46       ` Jerry Snitselaar
2020-12-05  1:43 ` [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count Jerry Snitselaar
2020-12-05  1:43   ` [Intel-gfx] " Jerry Snitselaar
2020-12-05  1:43   ` Jerry Snitselaar
2020-12-06 16:38   ` Thomas Gleixner
2020-12-06 16:38     ` [Intel-gfx] " Thomas Gleixner
2020-12-06 16:38     ` Thomas Gleixner
2020-12-06 21:33     ` Thomas Gleixner
2020-12-06 21:33       ` [Intel-gfx] " Thomas Gleixner
2020-12-06 21:33       ` Thomas Gleixner
2020-12-08  9:54       ` Jarkko Sakkinen
2020-12-08  9:54         ` [Intel-gfx] " Jarkko Sakkinen
2020-12-08  9:54         ` Jarkko Sakkinen
2020-12-06 21:47     ` Jerry Snitselaar
2020-12-06 21:47       ` [Intel-gfx] " Jerry Snitselaar
2020-12-06 21:47       ` Jerry Snitselaar
2020-12-06 23:38       ` Thomas Gleixner
2020-12-06 23:38         ` [Intel-gfx] " Thomas Gleixner
2020-12-06 23:38         ` Thomas Gleixner
2020-12-10  7:53     ` [Intel-gfx] " Joonas Lahtinen
2020-12-10  7:53       ` Joonas Lahtinen
2020-12-10  7:53       ` Joonas Lahtinen
2020-12-10 10:45       ` Tvrtko Ursulin
2020-12-10 10:45         ` Tvrtko Ursulin
2020-12-10 10:45         ` Tvrtko Ursulin
2020-12-10 16:35         ` Thomas Gleixner
2020-12-10 16:35           ` Thomas Gleixner
2020-12-10 16:35           ` Thomas Gleixner
2020-12-10 17:09           ` Tvrtko Ursulin
2020-12-10 17:09             ` Tvrtko Ursulin
2020-12-10 17:09             ` Tvrtko Ursulin
2020-12-10 17:44             ` Thomas Gleixner
2020-12-10 17:44               ` Thomas Gleixner
2020-12-10 17:44               ` Thomas Gleixner
2020-12-10 17:51               ` Tvrtko Ursulin
2020-12-10 17:51                 ` Tvrtko Ursulin
2020-12-10 17:51                 ` Tvrtko Ursulin
2020-12-05  1:43 ` [PATCH v3 3/4] tpm_tis: Disable interrupts if interrupt storm detected Jerry Snitselaar
2020-12-05  1:43   ` [Intel-gfx] " Jerry Snitselaar
2020-12-05  1:43   ` Jerry Snitselaar
2020-12-06 19:26   ` Thomas Gleixner
2020-12-06 19:26     ` [Intel-gfx] " Thomas Gleixner
2020-12-06 19:26     ` Thomas Gleixner
2020-12-07 19:28     ` Jason Gunthorpe
2020-12-07 19:28       ` Jason Gunthorpe
2020-12-07 19:58       ` James Bottomley
2020-12-07 19:58         ` [Intel-gfx] " James Bottomley
2020-12-07 19:58         ` James Bottomley
2020-12-08 17:43         ` Jarkko Sakkinen [this message]
2020-12-08 17:43           ` [Intel-gfx] " Jarkko Sakkinen
2020-12-08 17:43           ` Jarkko Sakkinen
2020-12-08 17:42       ` Jarkko Sakkinen
2020-12-08 17:42         ` [Intel-gfx] " Jarkko Sakkinen
2020-12-08 17:42         ` Jarkko Sakkinen
2020-12-05  1:43 ` [PATCH v3 4/4] tpm_tis: Disable Interrupts on the ThinkPad L490 Jerry Snitselaar
2020-12-05  1:43   ` [Intel-gfx] " Jerry Snitselaar
2020-12-05  1:43   ` Jerry Snitselaar
2020-12-05  1:55 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for tpm_tis: Detect interrupt storms Patchwork
2020-12-05  2:25 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-12-05  5:32 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2020-12-06 19:50 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for tpm_tis: Detect interrupt storms (rev2) Patchwork
2020-12-06 19:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-12-06 20:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-12-06 21:59 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201208174344.GC58213@kernel.org \
    --to=jarkko@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jgg@ziepe.ca \
    --cc=jsnitsel@redhat.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=peterhuewe@gmx.de \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.