On Tue, Mar 12, 2019 at 03:42:00PM -0700, Tadeusz Struk wrote: > Hi Jarkko, > On 3/11/19 6:09 AM, Jarkko Sakkinen wrote: > > Tadeusz, why on earth the code does not lock buffer_mutex?? Just noticed > > when I checked the function in question. It is an awful bug alone. > > Because the tpm_common_poll() just reads the flags and doesn't modify > them, so the logic was that if the response_length is not 0 or > response_read is flase then the first poll should return EPOLLIN > and if not, the application should call the poll again and only call read > if the EPOLLIN is set in the mask. It looks like the tpm_timeout_work() > kicks in and messes things out. 1. You have *two* variables that you read, which can lead up reading a partial state. 2. You are not using atomic_t even if there was one variable. > Looking at it again I think the response_read flag is redundant > and only the response_length should be used. Please provide a minimal fix to the issue. Only the fix for lock is needed and send a proper patch (did not read the code below). /Jarkko
