Re: Kernel 5.0 regression in /dev/tpm0 access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2019-03-12 at 15:42 -0700, Tadeusz Struk wrote:
> @@ -202,13 +196,15 @@ __poll_t tpm_common_poll(struct file *file,
> poll_table *wait)
>  	struct file_priv *priv = file->private_data;
>  	__poll_t mask = 0;
>  
> +	mutex_lock(&priv->buffer_mutex);
>  	poll_wait(file, &priv->async_wait, wait);
>  
> -	if (!priv->response_read || priv->response_length)
> +	if (priv->response_length)
>  		mask = EPOLLIN | EPOLLRDNORM;
>  	else
>  		mask = EPOLLOUT | EPOLLWRNORM;
>  
> +	mutex_unlock(&priv->buffer_mutex);

Isn't this setting us up for a deadlock?  If the work queued by write
hasn't run by the time you call poll, you take the buffer mutex and
sleep.  Now if the work runs, it blocks acquiring the mutex in
tpm_async_work and never calls wakeup on async_wait.

James




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux Kernel Hardening]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux