Re: 2.6.27-rc1 inconsistent lock state during boot time

[jay kumar]

On Wed, Jul 30, 2008 at 4:14 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 30 Jul 2008 15:07:14 +0530 "jay kumar" <jaykumarks@xxxxxxxxx> wrote:
>
>>          While  testing  2.6.27-rc1 ,  "inconsistent lock state"
>> warning appeared at boot time
>>          posting: dmesg  along with .config and hardware info.
>>
>>          commit 6e86841d05f371b5b9b86ce76c02aaee83352298
>>          Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
>>          Date:   Mon Jul 28 19:40:31 2008 -0700
>>
>> ..
>>
>> [    7.317402] debug: unmapping init memory c0571000..c0625000
>> [    7.324903]
>> [    7.324904] =================================
>> [    7.330825] [ INFO: inconsistent lock state ]
>> [    7.335218] 2.6.27-rc1 #5
>> [    7.337873] ---------------------------------
>> [    7.342273] inconsistent {hardirq-on-W} -> {in-hardirq-W} usage.
>> [    7.348325] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
>> [    7.353331]  (&port_lock_key){+-..}, at: [<c02e2eee>]
>> serial8250_interrupt+0x6e/0x160
>> [    7.361383] {hardirq-on-W} state was registered at:
>> [    7.366303]   [<c0155b65>] __lock_acquire+0x3b5/0x12e0
>> [    7.371559]   [<c0156b28>] lock_acquire+0x98/0xd0
>> [    7.376383]   [<c0404be2>] _spin_lock+0x32/0x60
>> [    7.381036]   [<c02e2a1d>] serial8250_startup+0x29d/0x640
>> [    7.386559]   [<c02dda91>] uart_startup+0x51/0x170
>> [    7.391471]   [<c02df58f>] uart_open+0xef/0x420
>> [    7.396124]   [<c02c9599>] tty_open+0x159/0x300
>> [    7.401396]   [<c01aac81>] chrdev_open+0x91/0x190
>> [    7.406220]   [<c01a63d6>] __dentry_open+0xb6/0x230
>> [    7.411220]   [<c01a6597>] nameidata_to_filp+0x47/0x60
>> [    7.416481]   [<c01b30de>] do_filp_open+0x19e/0x710
>> [    7.421480]   [<c01a61cd>] do_sys_open+0x4d/0xe0
>> [    7.426218]   [<c01a62c9>] sys_open+0x29/0x40
>> [    7.430698]   [<c0101146>] init_post+0x36/0x100
>> [    7.435353]   [<ffffffff>] 0xffffffff
>> [    7.439137] irq event stamp: 177720
>
> Does this fix it?
Fixed ..

Thanks

>
> From: Borislav Petkov <petkovbb@xxxxxxxxxxxxxx>
>
> serial8250_startup() doesn't disable interrupts while taking the &up->port.lock
> which might race against the interrupt handler serial8250_interrupt(), which
> when entered, will deadlock waiting for the lock to be released.
>
> Signed-off-by: Borislav Petkov <petkovbb@xxxxxxxxx>
> Tested-by: Ingo Molnar <mingo@xxxxxxx>
> Cc: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> ---
>
>  drivers/serial/8250.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -puN drivers/serial/8250.c~8250c-portlock-is-irq-safe drivers/serial/8250.c
> --- a/drivers/serial/8250.c~8250c-portlock-is-irq-safe
> +++ a/drivers/serial/8250.c
> @@ -1885,7 +1885,7 @@ static int serial8250_startup(struct uar
>                 * the interrupt is enabled.  Delays are necessary to
>                 * allow register changes to become visible.
>                 */
> -               spin_lock(&up->port.lock);
> +               spin_lock_irqsave(&up->port.lock, flags);
>                if (up->port.flags & UPF_SHARE_IRQ)
>                        disable_irq_nosync(up->port.irq);
>
> @@ -1901,7 +1901,7 @@ static int serial8250_startup(struct uar
>
>                if (up->port.flags & UPF_SHARE_IRQ)
>                        enable_irq(up->port.irq);
> -               spin_unlock(&up->port.lock);
> +               spin_unlock_irqrestore(&up->port.lock, flags);
>
>                /*
>                 * If the interrupt is not reasserted, setup a timer to
> _
>
>
--
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/