On 07/29/2015 04:12 AM, Taichi Kageyama wrote: > The following race conditions can happen when a serial port is used > as console. > > Case1: CPU_B is used to detect an interrupt from a serial port, > but it can have interrupts disabled during the waiting time. > Case2: CPU_B clears UART_IER just after CPU_A sets UART_IER and then > a serial port may not make an interrupt. > Case3: CPU_A sets UART_IER just after CPU_B clears UART_IER. > This is an unexpected behavior for serial8250_console_write(). > > CPU_A [autoconfig_irq] | CPU_B [serial8250_console_write] > ----------------------------|--------------------------------------- > | > probe_irq_on() | spin_lock_irqsave(&port->lock,) > serial_outp(,UART_IER,0x0f) | serial_out(,UART_IER,0) > udelay(20); | uart_console_write() > probe_irq_off() | > | spin_unlock_irqrestore(&port->lock,) > > Case1 and 2 can make autoconfig_irq() failed. > In these cases, the console doesn't work in interrupt mode and > "input overrun" (which can make operation mistakes) can happen > on some systems. Especially in the Case1, It is known that the > problem happens with high rate every boot once it occurs > because the boot sequence is always almost same. > > port mutex makes sure that the autoconfig operation is exclusive of > any other concurrent HW access except by the console operation. > console lock is required in autoconfig_irq(). > > Signed-off-by: Taichi Kageyama <t-kageyama@xxxxxxxxxxxxx> > Cc: Naoya Horiguchi <n-horiguchi@xxxxxxxxxxxxx> > Reviewed-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> Please resend this one patch to Greg as a non-RFC patch. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
