From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
linux-integrity@vger.kernel.org,
Guenter Roeck <linux@roeck-us.net>,
stable@vger.kernel.org, Peter Huewe <peterhuewe@gmx.de>,
Jason Gunthorpe <jgg@ziepe.ca>,
Stefan Berger <stefanb@linux.ibm.com>,
Wang Hai <wanghai38@huawei.com>
Subject: Re: [PATCH] tpm: WARN_ONCE() -> pr_warn_once() in tpm_tis_status()
Date: Tue, 02 Feb 2021 15:00:34 -0800 [thread overview]
Message-ID: <957c4efbfa22cb590ea8227718d1bbdcd690410a.camel@HansenPartnership.com> (raw)
In-Reply-To: <YBnR2YLitNJzvNBk@kernel.org>
On Wed, 2021-02-03 at 00:27 +0200, Jarkko Sakkinen wrote:
> On Tue, Feb 02, 2021 at 09:58:24AM -0800, James Bottomley wrote:
> > On Tue, 2021-02-02 at 11:26 -0600, Serge E. Hallyn wrote:
[...]
> > >
> > > Actually in this case I don't understand why _once, especially
> > > based on the comment. Would ratelimited not be better? So we
> > > can see if it happens repeatedly? Even better would be if we
> > > could see when it next gave a valid status after an invalid one.
> >
> > The reason was that we're trying to catch and kill paths to the
> > status where the locality is incorrect. If you do some operation
> > that finds an incorrect path the likelihood is you'll exercise it
> > more than once, but all we need to identify it is the call trace
> > from a single access. The symptom the user space process sees is a
> > TPM timeout, but we still have the in-kernel trace to tell us why.
>
> I don't agree with this reasoning. This warn could spun off also from
> chip not following TCG spec.
If it doesn't follow this basic part of the spec, the chip is unusable
by us anyway because we need the status to proceed with command
handling.
> The patch does provide the status code, which is always useful
> information.
In the wrong locality that will be bus not connected, so likely 0xff.
The most useful thing to know is what path triggered the condition
because the most likely cause is coding error.
James
next prev parent reply other threads:[~2021-02-02 23:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 15:33 [PATCH] tpm: WARN_ONCE() -> pr_warn_once() in tpm_tis_status() jarkko
2021-02-02 15:43 ` Guenter Roeck
2021-02-02 22:05 ` Jarkko Sakkinen
2021-02-02 16:05 ` Stefan Berger
2021-02-02 22:06 ` Jarkko Sakkinen
2021-02-02 16:46 ` Jason Gunthorpe
2021-02-02 22:25 ` Jarkko Sakkinen
2021-02-02 17:26 ` Serge E. Hallyn
2021-02-02 17:58 ` James Bottomley
2021-02-02 22:27 ` Jarkko Sakkinen
2021-02-02 22:29 ` Jarkko Sakkinen
2021-02-02 23:00 ` James Bottomley [this message]
2021-02-03 0:01 ` 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=957c4efbfa22cb590ea8227718d1bbdcd690410a.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=peterhuewe@gmx.de \
--cc=serge@hallyn.com \
--cc=stable@vger.kernel.org \
--cc=stefanb@linux.ibm.com \
--cc=wanghai38@huawei.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;
as well as URLs for NNTP newsgroup(s).