Re: TPM operation times out (very rarely)

[Jarkko Sakkinen <jarkko@kernel.org>]

On Wed, Mar 05, 2025 at 01:20:45PM +0100, Michal Suchánek wrote:
> On Sat, Mar 01, 2025 at 04:13:23AM +0200, Jarkko Sakkinen wrote:
> > On Mon, Feb 24, 2025 at 02:04:13PM +0100, Michal Suchánek wrote:
> > > On Mon, Feb 10, 2025 at 07:32:53PM +0200, Jarkko Sakkinen wrote:
> > > > On Mon Feb 10, 2025 at 6:18 PM EET, Jonathan McDowell wrote:
> > > > > Who then handles the ERESTARTSYS though? Part of the issues we've seen
> > > > > is the failure happens in a context save or load, which is all within
> > > > > the kernel rather than directly under the control of userspace. I'm
> > > > > guessing the HMAC changes are likely to hit similar problems. I think
> > > > > some level of timeout improvement in tpm_transmit is appropriate, if we
> > > > > can work out what it should be.
> > > > 
> > > > Right I get what you mean, not all transmits initiate from syscalls
> > > > And obviously this can happen without hmac too with tpmrm0.
> > > > 
> > > > Hmm... so I'm open for a patch that radically simplifies the state
> > > > change timeouts, i.e. sort of part of that old patch.
> > > 
> > > There is also another aspect to this:
> > > 
> > > What happens when the context save/load result is dropped on the floor?
> > 
> > Trying to understand what are you meaning by this. Are you speaking
> > about scenario where after the operation context operations fail
> > inside kernel?
> 
> I am speaking about the scenario when the opration succeeds but the
> kernel declares it a failure because it did not happen within the
> timeout.

OK got it, thanks.

I guess theoretically we could even never do timeout and let the caller
SIGINT.

> 
> Thanks
> 
> Michal

BR, Jarkko