From: Jarkko Sakkinen <jarkko@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Peter Huewe <peterhuewe@gmx.de>, Jason Gunthorpe <jgg@ziepe.ca>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
surenkj@amazon.com, noodles@meta.com, kernel-team@meta.com
Subject: Re: [PATCH 0/2] tpm: Stop retrying TPMs that have stopped working
Date: Thu, 12 Nov 2026 00:30:31 +0200 [thread overview]
Message-ID: <avTsh6pCI-sRGAJp@kernel.org> (raw)
In-Reply-To: <20261111-tpm_unresponsive-v1-0-42ac1b965eb9@debian.org>
On Wed, Nov 11, 2026 at 01:57:32AM -0800, Breno Leitao wrote:
> On Meta's datacenter, given the size, TPMs that stop working write about
> 54 million lines a day to the kernel log, because nothing in the kernel
> gives up on them.
>
> Two cases make up nearly all of it.
>
> Some TPMs stop responding. Every command then fails only after the
> transport timeout, while the hwrng thread and userspace keep sending
> more.
>
> The goal is to retire TPM that are not properly working, similarly to
> what was done for EFI in commit 4b2c033b5bc971 ("efi/runtime-wrappers:
> retire the worker if a wedged call ever returns")
>
> This feature aim to disable the chip once its commands have kept timing,
> instead of keeping it in this desolate state.
>
> Disabling the chip makes the failure explicit: the log gets one line
> saying the TPM is disabled, and every later command fails at once
> instead of timing out.
>
> A health-check daemon, such as machine checker, can then detect
> the broken hardware and send the machine to repair.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Breno Leitao (2):
> tpm: Disable a TPM that stops responding
> tpm: Disable a TPM whose hwrng reads keep failing
>
> drivers/char/tpm/tpm-chip.c | 20 +++++++++++++++++++-
> drivers/char/tpm/tpm-interface.c | 29 +++++++++++++++++++++++++++++
> include/linux/tpm.h | 3 +++
> 3 files changed, 51 insertions(+), 1 deletion(-)
> ---
> base-commit: 630059a5a632377b9b7b487baccde92b7ae1dd47
> change-id: 20261110-tpm_unresponsive-a5f71c1db026
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
I think this good stuff so existential condition for having some changes
to address these issues is fulfilled.
I.e. debating the details through will likely lead to productive results
:-)
Br, Jarkko
next prev parent reply other threads:[~2026-11-11 22:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 9:57 Breno Leitao
2026-11-11 9:57 ` [PATCH 1/2] tpm: Disable a TPM that stops responding Breno Leitao
2026-11-11 22:14 ` Jarkko Sakkinen
2026-11-11 9:57 ` [PATCH 2/2] tpm: Disable a TPM whose hwrng reads keep failing Breno Leitao
2026-11-11 22:16 ` Jarkko Sakkinen
2026-11-11 22:20 ` Jarkko Sakkinen
2026-11-11 22:30 ` Jarkko Sakkinen [this message]
2026-11-11 22:43 ` [PATCH 0/2] tpm: Stop retrying TPMs that have stopped working Jarkko Sakkinen
2026-11-11 22:46 ` Jarkko Sakkinen
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=avTsh6pCI-sRGAJp@kernel.org \
--to=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noodles@meta.com \
--cc=peterhuewe@gmx.de \
--cc=surenkj@amazon.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®