Re: [BUG] mysterious tty deadlock

[Russell King]

On Wed, Aug 28, 2002 at 03:25:20PM -0700, Andrew Morton wrote:
> William Lee Irwin III wrote:
> > 
> > One such stuck process had the following backtrace:
> > 
> > #0  schedule_timeout (timeout=-150765944) at timer.c:864
> 
> schedule_timeout is FASTCALL, which confuses gdb's stack crawler
> somewhat.
> 
> > #1  0xc01a28a3 in uart_wait_until_sent (tty=0xf7669000, timeout=2147483647)
> >     at core.c:1320
> 
> Might be a bit racy?
> 
> --- 2.5.32/drivers/serial/core.c~serial-race	Wed Aug 28 15:22:22 2002
> +++ 2.5.32-akpm/drivers/serial/core.c	Wed Aug 28 15:22:26 2002
> @@ -1315,13 +1315,14 @@ static void uart_wait_until_sent(struct 
>  	 * 'timeout' / 'expire' give us the maximum amount of time
>  	 * we wait.
>  	 */
> +	set_current_state(TASK_INTERRUPTIBLE);
>  	while (!port->ops->tx_empty(port)) {
> -		set_current_state(TASK_INTERRUPTIBLE);
>  		schedule_timeout(char_time);
>  		if (signal_pending(current))
>  			break;
>  		if (time_after(jiffies, expire))
>  			break;
> +		set_current_state(TASK_INTERRUPTIBLE);
>  	}
>  	set_current_state(TASK_RUNNING); /* might not be needed */
>  }

Patch looks good, as far as correctness goes.  However, since char_time
will be the amount of time for one character, we should never sleep long
enough for the user to notice this slip-up.

If people are seeing deadlocks, I agree with wli that there's something
very wrong elsewhere.

-- 
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html