Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1191374 > unrolled thread

Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions

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.

Contents

  Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race  conditions "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org> - 2015-07-24 00:40 +0200
    Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race  conditions Taichi Kageyama <t-kageyama@cp.jp.nec.com> - 2015-07-29 10:30 +0200

#1191374 — Re: [PATCH 1/2] serial: 8250: Fix autoconfig_irq() to avoid race conditions

On Fri, Jun 05, 2015 at 09:57:40AM +0000, 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.
> 
> Signed-off-by: Taichi Kageyama <t-kageyama@cp.jp.nec.com>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>   drivers/tty/serial/8250/8250_core.c |    6 ++++++
>   1 files changed, 6 insertions(+), 0 deletions(-)

Does not apply to 4.2-rc3 :(
--
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/

[toc] | [next] | [standalone]

#1194931

On 2015/07/24 7:32, gregkh@linuxfoundation.org wrote:
> On Fri, Jun 05, 2015 at 09:57:40AM +0000, 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.
>>
>> Signed-off-by: Taichi Kageyama <t-kageyama@cp.jp.nec.com>
>> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
>> Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
>> ---
>>   drivers/tty/serial/8250/8250_core.c |    6 ++++++
>>   1 files changed, 6 insertions(+), 0 deletions(-)
> 
> Does not apply to 4.2-rc3 :(
> 

Sorry for the trouble and late reply.
It's my fault. It was encoded as base64 by Exchange.
I sent new patch set including this patch.
I updated commit log.


Regards,
Taichi--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web