niedz., 6 lis 2022 o 20:49 Jarkko Sakkinen <jarkko@xxxxxxxxxx> napisał(a): > > On Thu, Nov 03, 2022 at 03:54:48PM +0100, Jan Dabros wrote: > > Currently tpm transactions are executed unconditionally in > > tpm_pm_suspend() function, what may lead to races with other tpm > > accessors in the system. > > > > Add proper locking mechanisms by calling tpm_try_get_ops() which is a > > wrapper on tpm_chip_start(). > > > > Signed-off-by: Jan Dabros <jsd@xxxxxxxxxxxx> > > AFAIK processes are freezed before suspend callbacks are called, and > the callbacks are called sequentially. I have no idea what is meant > by "TPM accessor" here. User space processes are freezed before suspend, but kernel threads are not freezable by default. In my particular case it was a hwrng thread started from drivers/char/hw_random/core.c - I was referring to it as "TPM accessor". For sure I should be more precise in a commit msg. > Please describe the concurrency scenario in the commit message where the > race could happen, if it is hard to reproduce, and add an appropriate fixes > tag. I will describe my scenario in more detail in the next version. Regarding the "fixes" tag - I'm not too familiar with it, but looking at the kernel submission guide, "fixes" should be used either when there was a particular commit in the past which introduced the bug or if a patch fixes an already logged bug entry (so that one can paste URL). In my case both are not applicable, so please advise what exactly I should put after this tag? Best Regards, Jan
