From: Stefan Berger <[email protected]>
Revert the patches that were fixing the probing of interrupts due
to reports of interrupt stroms on some systems
The following Linux kernel versions are affected:
- 5.4
- 5.3.4 and later
- 5.2.19 and later
Stefan Berger (2):
tpm: Revert "tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for
interrupts"
tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's"
drivers/char/tpm/tpm_tis_core.c | 3 ---
1 file changed, 3 deletions(-)
--
2.14.5
From: Stefan Berger <[email protected]>
Revert the patch that was turning the TPM on before probing for IRQs.
Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's")
Signed-off-by: Stefan Berger <[email protected]>
Reported-by: Jerry Snitselaar <[email protected]>
Cc: [email protected]
---
drivers/char/tpm/tpm_tis_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 5dc52c4e2292..27c6ca031e23 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -1059,7 +1059,6 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
goto out_err;
}
- tpm_chip_start(chip);
if (irq) {
tpm_tis_probe_irq_single(chip, intmask, IRQF_SHARED,
irq);
@@ -1069,7 +1068,6 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
} else {
tpm_tis_probe_irq(chip, intmask);
}
- tpm_chip_stop(chip);
}
rc = tpm_chip_register(chip);
--
2.14.5
From: Stefan Berger <[email protected]>
Revert the patch that was setting the TPM_CHIP_FLAG_IRQ before probing for
interrupts.
Fixes: 1ea32c83c699 ("tpm_tis_core: Set TPM_CHIP_FLAG_IRQ before probing for interrupts")
Signed-off-by: Stefan Berger <[email protected]>
Reported-by: Jerry Snitselaar <[email protected]>
Cc: [email protected]
---
drivers/char/tpm/tpm_tis_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 8af2cee1a762..5dc52c4e2292 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -1060,7 +1060,6 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
}
tpm_chip_start(chip);
- chip->flags |= TPM_CHIP_FLAG_IRQ;
if (irq) {
tpm_tis_probe_irq_single(chip, intmask, IRQF_SHARED,
irq);
--
2.14.5
On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
> From: Stefan Berger <[email protected]>
>
> Revert the patches that were fixing the probing of interrupts due
> to reports of interrupt stroms on some systems
Can you explain how reverting is going to fix the issue?
This is wrong way to move forward. The root cause must be identified
first and then decide actions like always in any situation.
/Jarkko
On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
> On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
>> From: Stefan Berger <[email protected]>
>>
>> Revert the patches that were fixing the probing of interrupts due
>> to reports of interrupt stroms on some systems
> Can you explain how reverting is going to fix the issue?
The reverts fix 'the interrupt storm issue' that they are causing on
some systems but don't fix the issue with the interrupt mode not being
used. I was hoping Jerry would get access to a system faster but this
didn't seem to be the case. So sending these patches seemed the better
solution than leaving 5.4.x with the problem but going back to when it
worked 'better.'
>
> This is wrong way to move forward. The root cause must be identified
> first and then decide actions like always in any situation.
>
> /Jarkko
On Sun Dec 01 19, Stefan Berger wrote:
>On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
>>On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
>>>From: Stefan Berger <[email protected]>
>>>
>>>Revert the patches that were fixing the probing of interrupts due
>>>to reports of interrupt stroms on some systems
>>Can you explain how reverting is going to fix the issue?
>
>
>The reverts fix 'the interrupt storm issue' that they are causing on
>some systems but don't fix the issue with the interrupt mode not being
>used. I was hoping Jerry would get access to a system faster but this
>didn't seem to be the case. So sending these patches seemed the better
>solution than leaving 5.4.x with the problem but going back to when it
>worked 'better.'
>
I finally heard back from IT support, and unfortunately they don't
have any T490s systems to give out on temp loan. So I can only send
patched kernels to the end user that had the problem.
>
>>
>>This is wrong way to move forward. The root cause must be identified
>>first and then decide actions like always in any situation.
>>
>>/Jarkko
>
>
On Mon, Dec 02, 2019 at 11:55:20AM -0700, Jerry Snitselaar wrote:
> On Sun Dec 01 19, Stefan Berger wrote:
> > On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
> > > On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
> > > > From: Stefan Berger <[email protected]>
> > > >
> > > > Revert the patches that were fixing the probing of interrupts due
> > > > to reports of interrupt stroms on some systems
> > > Can you explain how reverting is going to fix the issue?
> >
> >
> > The reverts fix 'the interrupt storm issue' that they are causing on
> > some systems but don't fix the issue with the interrupt mode not being
> > used. I was hoping Jerry would get access to a system faster but this
> > didn't seem to be the case. So sending these patches seemed the better
> > solution than leaving 5.4.x with the problem but going back to when it
> > worked 'better.'
> >
>
> I finally heard back from IT support, and unfortunately they don't
> have any T490s systems to give out on temp loan. So I can only send
> patched kernels to the end user that had the problem.
At least it is a fact that tpm_chip_stop() is called too early and that
is destined to cause issues.
Should I bake a patch or do you have already something?
/Jarkko
On Mon Dec 09 19, Jarkko Sakkinen wrote:
>On Mon, Dec 02, 2019 at 11:55:20AM -0700, Jerry Snitselaar wrote:
>> On Sun Dec 01 19, Stefan Berger wrote:
>> > On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
>> > > On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
>> > > > From: Stefan Berger <[email protected]>
>> > > >
>> > > > Revert the patches that were fixing the probing of interrupts due
>> > > > to reports of interrupt stroms on some systems
>> > > Can you explain how reverting is going to fix the issue?
>> >
>> >
>> > The reverts fix 'the interrupt storm issue' that they are causing on
>> > some systems but don't fix the issue with the interrupt mode not being
>> > used. I was hoping Jerry would get access to a system faster but this
>> > didn't seem to be the case. So sending these patches seemed the better
>> > solution than leaving 5.4.x with the problem but going back to when it
>> > worked 'better.'
>> >
>>
>> I finally heard back from IT support, and unfortunately they don't
>> have any T490s systems to give out on temp loan. So I can only send
>> patched kernels to the end user that had the problem.
>
>At least it is a fact that tpm_chip_stop() is called too early and that
>is destined to cause issues.
>
>Should I bake a patch or do you have already something?
>
>/Jarkko
>
This is what I'm currently building:
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 270f43acbb77..17184c07eb51 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -899,13 +899,13 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
if (wait_startup(chip, 0) != 0) {
rc = -ENODEV;
- goto out_err;
+ goto out_start;
}
/* Take control of the TPM's interrupt hardware and shut it off */
rc = tpm_tis_read32(priv, TPM_INT_ENABLE(priv->locality), &intmask);
if (rc < 0)
- goto out_err;
+ goto out_start;
intmask |= TPM_INTF_CMD_READY_INT | TPM_INTF_LOCALITY_CHANGE_INT |
TPM_INTF_DATA_AVAIL_INT | TPM_INTF_STS_VALID_INT;
@@ -914,9 +914,8 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
rc = tpm_chip_start(chip);
if (rc)
- goto out_err;
+ goto out_start;
rc = tpm2_probe(chip);
- tpm_chip_stop(chip);
if (rc)
goto out_err;
@@ -980,7 +979,6 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
goto out_err;
}
- tpm_chip_start(chip);
chip->flags |= TPM_CHIP_FLAG_IRQ;
if (irq) {
tpm_tis_probe_irq_single(chip, intmask, IRQF_SHARED,
@@ -991,18 +989,17 @@ int tpm_tis_core_init(struct device *dev, struct tpm_tis_data *priv, int irq,
} else {
tpm_tis_probe_irq(chip, intmask);
}
- tpm_chip_stop(chip);
}
+ tpm_chip_stop(chip);
rc = tpm_chip_register(chip);
if (rc)
- goto out_err;
-
- if (chip->ops->clk_enable != NULL)
- chip->ops->clk_enable(chip, false);
+ goto out_start;
return 0;
out_err:
+ tpm_chip_stop(chip);
+out_start:
if ((chip->ops != NULL) && (chip->ops->clk_enable != NULL))
chip->ops->clk_enable(chip, false);
On Mon, Dec 09, 2019 at 02:55:35PM -0700, Jerry Snitselaar wrote:
> On Mon Dec 09 19, Jarkko Sakkinen wrote:
> > On Mon, Dec 02, 2019 at 11:55:20AM -0700, Jerry Snitselaar wrote:
> > > On Sun Dec 01 19, Stefan Berger wrote:
> > > > On 11/29/19 5:37 PM, Jarkko Sakkinen wrote:
> > > > > On Tue, Nov 26, 2019 at 08:17:51AM -0500, Stefan Berger wrote:
> > > > > > From: Stefan Berger <[email protected]>
> > > > > >
> > > > > > Revert the patches that were fixing the probing of interrupts due
> > > > > > to reports of interrupt stroms on some systems
> > > > > Can you explain how reverting is going to fix the issue?
> > > >
> > > >
> > > > The reverts fix 'the interrupt storm issue' that they are causing on
> > > > some systems but don't fix the issue with the interrupt mode not being
> > > > used. I was hoping Jerry would get access to a system faster but this
> > > > didn't seem to be the case. So sending these patches seemed the better
> > > > solution than leaving 5.4.x with the problem but going back to when it
> > > > worked 'better.'
> > > >
> > >
> > > I finally heard back from IT support, and unfortunately they don't
> > > have any T490s systems to give out on temp loan. So I can only send
> > > patched kernels to the end user that had the problem.
> >
> > At least it is a fact that tpm_chip_stop() is called too early and that
> > is destined to cause issues.
> >
> > Should I bake a patch or do you have already something?
> >
> > /Jarkko
> >
>
> This is what I'm currently building:
With a quick skim looks what I had in mind.
/Jarkko
On Tue, 2019-11-26 at 08:17 -0500, Stefan Berger wrote:
> From: Stefan Berger <[email protected]>
>
> Revert the patch that was turning the TPM on before probing for IRQs.
>
> Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing
> IRQ's")
> Signed-off-by: Stefan Berger <[email protected]>
> Reported-by: Jerry Snitselaar <[email protected]>
> Cc: [email protected]
> ---
> drivers/char/tpm/tpm_tis_core.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_tis_core.c
> b/drivers/char/tpm/tpm_tis_core.c
> index 5dc52c4e2292..27c6ca031e23 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -1059,7 +1059,6 @@ int tpm_tis_core_init(struct device *dev,
> struct tpm_tis_data *priv, int irq,
> goto out_err;
> }
>
> - tpm_chip_start(chip);
> if (irq) {
> tpm_tis_probe_irq_single(chip, intmask,
> IRQF_SHARED,
> irq);
> @@ -1069,7 +1068,6 @@ int tpm_tis_core_init(struct device *dev,
> struct tpm_tis_data *priv, int irq,
> } else {
> tpm_tis_probe_irq(chip, intmask);
> }
> - tpm_chip_stop(chip);
> }
>
> rc = tpm_chip_register(chip);
This patch is completely bogus: it's not a full revert of what it
claims to be. With this patch applied all my TIS TPMs are returning
0xff to the status reads because the locality hasn't been properly
requested. The chip has to be started somewhere for the interrupt
probe to work on these TPMs ... what the original patch did was
eliminate a bunch of start/stops for a global one. However, if the
global one isn't working we should have gone back to the bunch of
smaller ones i.e. a full revert.
The only real manifestation of the problems this patch causes is that
interrupts never get enabled on TIS TPMs that have this issue, but they
still work via polling.
The below is what fixes this for me with the minimum possible extend of
additional chip start/stop in the code. This should be checked against
the previous failing laptops.
James
---
From: James Bottomley <[email protected]>
Subject: [PATCH] tpm_tis: fix interrupt probing
When we send a command into the TPM core, the TPM must be started
otherwise the register reads can be bogus. There have been several
bug reports about doing this inside the TIS core, so fix the issue by
adding an external version of the tpm2_get_tpm_pt() call which adds a
tpm ops get/put to set up the TPM correctly before the command is
sent.
Fixes: aa4a63dd9816 (tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's")
Signed-off-by: James Bottomley <[email protected]>
---
drivers/char/tpm/tpm.h | 2 ++
drivers/char/tpm/tpm2-cmd.c | 30 ++++++++++++++++++++++++++++++
drivers/char/tpm/tpm_tis_core.c | 2 +-
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 947d1db0a5cc..041b0b5bd2a5 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -223,6 +223,8 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
u32 *value, const char *desc);
+ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id,
+ u32 *value, const char *desc);
ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
int tpm2_auto_startup(struct tpm_chip *chip);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index eff1f12d981a..9b84158c5a9e 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -407,6 +407,36 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id, u32 *value,
}
EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt);
+/**
+ * tpm2_get_tpm_pt_cmd() - get value of a TPM_CAP_TPM_PROPERTIES type property
+ * @chip: a &tpm_chip instance
+ * @property_id: property ID.
+ * @value: output variable.
+ * @desc: passed to tpm_transmit_cmd()
+ *
+ * This calls the necessary tpm_try_get_ops()/tpm_put_ops() around
+ * tpm2_get_tpm_pt() and must be called where it is used stand alone
+ * outside the core code.
+ *
+ * Return:
+ * 0 on success,
+ * -errno or a TPM return code otherwise
+ */
+ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id, u32 *value,
+ const char *desc)
+{
+ ssize_t rc;
+
+ rc = tpm_try_get_ops(chip);
+ if (rc)
+ return rc;
+ rc = tpm2_get_tpm_pt(chip, property_id, value, desc);
+ tpm_put_ops(chip);
+
+ return rc;
+}
+EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt_cmd);
+
/**
* tpm2_shutdown() - send a TPM shutdown command
*
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
index 92c51c6cfd1b..6b884badabe7 100644
--- a/drivers/char/tpm/tpm_tis_core.c
+++ b/drivers/char/tpm/tpm_tis_core.c
@@ -753,7 +753,7 @@ static int tpm_tis_gen_interrupt(struct tpm_chip *chip)
cap_t cap;
if (chip->flags & TPM_CHIP_FLAG_TPM2)
- return tpm2_get_tpm_pt(chip, 0x100, &cap2, desc);
+ return tpm2_get_tpm_pt_cmd(chip, 0x100, &cap2, desc);
else
return tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, desc,
0);
--
2.28.0
On Sun, Sep 27, 2020 at 01:06:03PM -0700, James Bottomley wrote:
> On Tue, 2019-11-26 at 08:17 -0500, Stefan Berger wrote:
> > From: Stefan Berger <[email protected]>
> >
> > Revert the patch that was turning the TPM on before probing for IRQs.
> >
> > Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing
> > IRQ's")
> > Signed-off-by: Stefan Berger <[email protected]>
> > Reported-by: Jerry Snitselaar <[email protected]>
> > Cc: [email protected]
> > ---
> > drivers/char/tpm/tpm_tis_core.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_tis_core.c
> > b/drivers/char/tpm/tpm_tis_core.c
> > index 5dc52c4e2292..27c6ca031e23 100644
> > --- a/drivers/char/tpm/tpm_tis_core.c
> > +++ b/drivers/char/tpm/tpm_tis_core.c
> > @@ -1059,7 +1059,6 @@ int tpm_tis_core_init(struct device *dev,
> > struct tpm_tis_data *priv, int irq,
> > goto out_err;
> > }
> >
> > - tpm_chip_start(chip);
> > if (irq) {
> > tpm_tis_probe_irq_single(chip, intmask,
> > IRQF_SHARED,
> > irq);
> > @@ -1069,7 +1068,6 @@ int tpm_tis_core_init(struct device *dev,
> > struct tpm_tis_data *priv, int irq,
> > } else {
> > tpm_tis_probe_irq(chip, intmask);
> > }
> > - tpm_chip_stop(chip);
> > }
> >
> > rc = tpm_chip_register(chip);
>
> This patch is completely bogus: it's not a full revert of what it
> claims to be. With this patch applied all my TIS TPMs are returning
> 0xff to the status reads because the locality hasn't been properly
> requested. The chip has to be started somewhere for the interrupt
> probe to work on these TPMs ... what the original patch did was
> eliminate a bunch of start/stops for a global one. However, if the
> global one isn't working we should have gone back to the bunch of
> smaller ones i.e. a full revert.
>
> The only real manifestation of the problems this patch causes is that
> interrupts never get enabled on TIS TPMs that have this issue, but they
> still work via polling.
>
> The below is what fixes this for me with the minimum possible extend of
> additional chip start/stop in the code. This should be checked against
> the previous failing laptops.
>
> James
>
> ---
>
> From: James Bottomley <[email protected]>
> Subject: [PATCH] tpm_tis: fix interrupt probing
>
> When we send a command into the TPM core, the TPM must be started
> otherwise the register reads can be bogus. There have been several
> bug reports about doing this inside the TIS core, so fix the issue by
> adding an external version of the tpm2_get_tpm_pt() call which adds a
> tpm ops get/put to set up the TPM correctly before the command is
> sent.
>
> Fixes: aa4a63dd9816 (tpm: Revert "tpm_tis_core: Turn on the TPM before probing IRQ's")
> Signed-off-by: James Bottomley <[email protected]>
> ---
> drivers/char/tpm/tpm.h | 2 ++
> drivers/char/tpm/tpm2-cmd.c | 30 ++++++++++++++++++++++++++++++
> drivers/char/tpm/tpm_tis_core.c | 2 +-
> 3 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 947d1db0a5cc..041b0b5bd2a5 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -223,6 +223,8 @@ int tpm2_pcr_extend(struct tpm_chip *chip, u32 pcr_idx,
> int tpm2_get_random(struct tpm_chip *chip, u8 *dest, size_t max);
> ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id,
> u32 *value, const char *desc);
> +ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id,
> + u32 *value, const char *desc);
>
> ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
> int tpm2_auto_startup(struct tpm_chip *chip);
> diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> index eff1f12d981a..9b84158c5a9e 100644
> --- a/drivers/char/tpm/tpm2-cmd.c
> +++ b/drivers/char/tpm/tpm2-cmd.c
> @@ -407,6 +407,36 @@ ssize_t tpm2_get_tpm_pt(struct tpm_chip *chip, u32 property_id, u32 *value,
> }
> EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt);
>
> +/**
> + * tpm2_get_tpm_pt_cmd() - get value of a TPM_CAP_TPM_PROPERTIES type property
> + * @chip: a &tpm_chip instance
> + * @property_id: property ID.
> + * @value: output variable.
> + * @desc: passed to tpm_transmit_cmd()
> + *
> + * This calls the necessary tpm_try_get_ops()/tpm_put_ops() around
> + * tpm2_get_tpm_pt() and must be called where it is used stand alone
> + * outside the core code.
> + *
> + * Return:
> + * 0 on success,
> + * -errno or a TPM return code otherwise
> + */
> +ssize_t tpm2_get_tpm_pt_cmd(struct tpm_chip *chip, u32 property_id, u32 *value,
> + const char *desc)
> +{
> + ssize_t rc;
> +
> + rc = tpm_try_get_ops(chip);
> + if (rc)
> + return rc;
> + rc = tpm2_get_tpm_pt(chip, property_id, value, desc);
> + tpm_put_ops(chip);
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(tpm2_get_tpm_pt_cmd);
Hi, same comment as for the other, i.e. rename the function that does
not have get/put_ops as __tpm2_get_tpm_pt(). Otherwise, fine. Thank
you.
/Jarkko