Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1180301 > unrolled thread
| Started by | Peter Hurley <peter@hurleysoftware.com> |
|---|---|
| First post | 2015-07-09 01:40 +0200 |
| Last post | 2015-07-09 01:40 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions Peter Hurley <peter@hurleysoftware.com> - 2015-07-09 01:40 +0200
| From | Peter Hurley <peter@hurleysoftware.com> |
|---|---|
| Date | 2015-07-09 01:40 +0200 |
| Subject | Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions |
| Message-ID | <pK76y-14A-5@gated-at.bofh.it> |
On 06/05/2015 05:57 AM, Taichi Kageyama wrote: > The following race conditions can happen if a serial is used as console. > Case1. CPU_B handles an interrupt from a serial > autoconfig_irq() fails whether the interrupt is raised or not > if CPU_B is disabled to handle interrupts for longer than it expects. > Case2. CPU_B clears UART_IER just after CPU_A sets UART_IER > A serial may not make an interrupt. > autoconfig_irq() can fail if the interrupt is not raised. > Case3. CPU_A sets UART_IER just after CPU_B clears UART_IER > This is an unexpected behavior for uart_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,) > ----------------------------------------------------------------- > > If autoconfig_irq() fails, the console doesn't work in interrupt mode, > the mode cannot be changed anymore, and "input overrun" > (which can make operation mistakes) happens easily. > This problem happens with high rate every boot once it occurs > because the boot sequence is always almost same. Reviewed-by: Peter Hurley <peter@hurleysoftware.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to top | Article view | linux.kernel
csiph-web