Re: [PATCH] tty: Fix possible deadlock in tty_buffer_flush

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

 



On 08. 05. 24, 11:30, kovalev@xxxxxxxxxxxx wrote:
From: Vasiliy Kovalev <kovalev@xxxxxxxxxxxx>

A possible scenario in which a deadlock may occur is as follows:

flush_to_ldisc() {

   mutex_lock(&buf->lock);

   tty_port_default_receive_buf() {
     tty_ldisc_receive_buf() {
       n_tty_receive_buf2() {
	n_tty_receive_buf_common() {
	  n_tty_receive_char_special() {
	    isig() {
	      tty_driver_flush_buffer() {
		pty_flush_buffer() {
		  tty_buffer_flush() {

		    mutex_lock(&buf->lock); (DEADLOCK)

flush_to_ldisc() and tty_buffer_flush() functions they use the same mutex
(&buf->lock), but not necessarily the same struct tty_bufhead object.

"not necessarily" -- so does it mean that it actually can happen (and we should fix it) or not at all (and we should annotate the mutex)?

However, you should probably use a separate mutex for the
tty_buffer_flush() function to exclude such a situation.
...

Cc: stable@xxxxxxxxxxxxxxx

What commit does this fix?

--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -226,7 +226,7 @@ void tty_buffer_flush(struct tty_struct *tty, struct tty_ldisc *ld)
atomic_inc(&buf->priority); - mutex_lock(&buf->lock);
+	mutex_lock(&buf->flush_mtx);

Hmm, how does this protect against concurrent buf pickup. We free it here and the racing thread can start using it, or?

  	/* paired w/ release in __tty_buffer_request_room; ensures there are
  	 * no pending memory accesses to the freed buffer
  	 */

thanks,
--
js
suse labs





[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux