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
