[Impact]
It has been reported that some TIS based TPMs are giving unexpected errors when using the O_NONBLOCK path of the TPM device. The problem is that some TPMs don't like it when you get and then relinquish a locality (as the tpm_try_get_ops()/tpm_put_ops() pair does) without sending a command. This currently happens all the time in the O_NONBLOCK write path. This affects Nuvoton TPMs and was a regression caused by the patch d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode").
Link: https://patchwork.kernel.org/patch/11576453/
[Fix]
Fix this by moving the tpm_try_get_ops()
further down the code to after the O_NONBLOCK determination is made.
This is safe because the priv->buffer_mutex still protects the priv
state being modified.
[Regression Risk]
Low. This patch only for fix the patch d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode").
Link: https:/ /patchwork. kernel. org/patch/ 11576453/
[Impact] get_ops( )/tpm_put_ ops() pair does) without sending a command. This currently happens all the time in the O_NONBLOCK write path. This affects Nuvoton TPMs and was a regression caused by the patch d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode"). /patchwork. kernel. org/patch/ 11576453/
It has been reported that some TIS based TPMs are giving unexpected errors when using the O_NONBLOCK path of the TPM device. The problem is that some TPMs don't like it when you get and then relinquish a locality (as the tpm_try_
Link: https:/
[Fix]
Fix this by moving the tpm_try_get_ops()
further down the code to after the O_NONBLOCK determination is made.
This is safe because the priv->buffer_mutex still protects the priv
state being modified.
[Regression Risk]
Low. This patch only for fix the patch d23d12484307 ("tpm: fix invalid locking in NONBLOCKING mode").