Re: Deadlock in serial driver 2.6.x

[Martin Kögler]

On Thu, Feb 03, 2005 at 10:21:12AM -0800, Andrew Morton wrote:
> The "echo method" method sounds good.  Do we think that's feasible for
> 2.6.11, or would it be safer to disable low-latency mode for that driver?

As a temporary workaround, dropping the lock should also work:

--- linux-2.6.10/drivers/serial/8250.old.c      2005-02-03 14:07:48.557609200 +0100
+++ linux-2.6.10/drivers/serial/8250.c  2005-02-03 14:09:00.687887525 +0100
@@ -987,7 +987,11 @@
		   unsafe. It should be fixed ASAP */
	        if (unlikely(tty->flip.count >= TTY_FLIPBUF_SIZE)) {
		        if(tty->low_latency)
-                               tty_flip_buffer_push(tty);
+                         {
+                           spin_unlock(&up->port.lock);
+                           tty_flip_buffer_push(tty);
+                           spin_lock(&up->port.lock);
+                         }
    		        /* If this failed then we will throw away the
		           bytes but must do so to clear interrupts */
								      }
@@ -1058,7 +1062,9 @@
	ignore_char:
    	        lsr = serial_inp(up, UART_LSR);
        } while ((lsr & UART_LSR_DR) && (max_count-- > 0));
+       spin_unlock(&up->port.lock);
        tty_flip_buffer_push(tty);
+       spin_lock(&up->port.lock);
        *status = lsr;
 }

An other serial interrupt can not disturbed, because it will be blocked by the interrupt lock.
All other direct access to the UART seems to be protected by the port lock, so they may be only
execectued, while tty_flip_buffer_push is running and is not accessing the port.

I have this patch running on a 2.6.10 Kernel (Fedora Core 2 Version) and low latency mode
works without any problems (with and without SMP).

If that patch works under all conditons, I can't say. It may cause degrade the performance,
but for my work, I can't see any effect.

mfg Martin Kögler
e9925248@xxxxxxxxxxxxxxxxxx
PS: Please CC me on replies.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/