On Sat, Feb 08, 2025 at 10:29:55PM +0200, Jarkko Sakkinen wrote: > On Fri, Feb 07, 2025 at 09:26:16AM +0000, Jonathan McDowell wrote: > > > The whole arithmetic with timeout_a/b/c is mostly gibberish and could > > > be replaced with a single "max" constant without issues (just set it > > > large enough). > > > > > > They could be all be replaced with let's say 3s timeout in a constant. > > > > This appears to have come up before: > > > > https://lore.kernel.org/linux-integrity/358e89ed2b766d51b5f57abf31ab7a925ac63379.1552348123.git.calvinowens@xxxxxx/ > > > > That patch was deemed overly complex and it was suggested to split it > > up; I can't find any indication that was ever done which I guess is why > > the discussion died off. > > Looking back I suggest splitting timeouts and durations into separate > patches: > > https://lore.kernel.org/linux-integrity/20190312145553.GB6682@xxxxxxxxxxxxxxx/ Yup, that seems to be where it all died out from what I could find. > > So just to clarify, this more recent patch is working around a situation > > where the status register gets stuck and needs a complete retry of the > > command send - it's an Infineon errata, not something that would be > > fixed with a longer timeout. > > Hmm... please shout if I ignore something but if we could -ERESTARTSYS > semantics here that should ignite completely new transmit flow, wouldn't > it? 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. Likewise for the Infineon errata I think an internal retry makes sense, because it could happen for a number of internally generated kernel reasons as well as a userspace sent command. J. -- How I wish, how I wish you were here.
