On Wed, 2024-07-17 at 12:31 +0300, Jarkko Sakkinen wrote: > On Wed, 2024-07-17 at 12:27 +0300, Jarkko Sakkinen wrote: > > On Tue, 2024-07-16 at 15:32 -0400, James Bottomley wrote: > > > On Tue, 2024-07-16 at 21:52 +0300, Jarkko Sakkinen wrote: > > > [...] > > > > Further, 'handles' was incorrectly place to struct tpm_buf, as tpm- > > > > buf.c does manage its state. It is easy to grep that only piece of > > > > code that actually uses the field is tpm2-sessions.c. > > > > > > > > Address the issues by moving the variable to struct tpm_chip. > > > > > > That's really not a good idea, you should keep counts local to the > > > structures they're counting, not elsewhere. > > > > > > tpm_buf->handles counts the number of handles present in the command > > > encoded in a particular tpm_buf. Right at the moment we only ever > > > construct one tpm_buf per tpm (i.e. per tpm_chip) at any one time, so > > > you can get away with moving handles into tpm_chip. If we ever > > > constructed more than one tpm_buf per chip, the handles count would > > > become corrupted. > > > > It is not an idea. That count is in the wrong place. Buffer code > > has no use for it. > > Also you are misleading here again. Depending on context tpm_buf > stores different data, including handles. These false claims can be also proved wrong by trivial git grep, which clearly shows its scope. BR, Jarkko
