On Wed, Mar 13, 2019 at 03:59:26PM +0200, Jarkko Sakkinen wrote: > 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). Are you planning to submit a fix for this? /Jarkko
