[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1268686865.2824.4.camel@edumazet-laptop>
Date: Mon, 15 Mar 2010 22:01:05 +0100
From: Eric Dumazet <eric.dumazet@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Francois Romieu <romieu@...zoreil.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
David Miller <davem@...emloft.net>
Subject: Re: inconsistent lock state
Le lundi 08 mars 2010 à 13:51 +0100, Oleg Nesterov a écrit :
> Sergey Senozhatsky wrote:
> >
> > Hello,
> >
> > Hardly reproducible.
> > /*
> > * 2.6.33. x86. ASUS f3jc
> > */
> >
> > [329645.010697] =================================
> > [329645.010699] [ INFO: inconsistent lock state ]
> > [329645.010703] 2.6.33-33-0-dbg #31
> > [329645.010705] ---------------------------------
> > [329645.010708] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
> >
> > ...
> >
> > [329645.011083] [<c128858d>] netif_receive_skb+0x340/0x360
> > [329645.011093] [<fd1ab6f4>] rtl8169_rx_interrupt+0x2bf/0x37e [r8169]
> > [329645.011100] [<fd1aba02>] rtl8169_reset_task+0x38/0xcd [r8169]
> > [329645.011105] [<c1044f71>] worker_thread+0x1ac/0x27c
>
> I don't understand this code, but at first glance drivers/net/r8169.c
> is obviously buggy.
>
> The work->func, rtl8169_reset_task(), calls rtl8169_rx_interrupt() ->
> netif_receive_skb(), and the last one may only be called from softirq.
>
Yes, this is wrong. In this context (process context, not softirq), we
should use netif_rx() or just drop frames if we are in reset phase.
Also, this driver schedules a reset in case a fifo error is reported in
rtl8169_rx_interrupt()
if (status & RxFOVF) {
rtl8169_schedule_work(dev, rtl8169_reset_task);
dev->stats.rx_fifo_errors++;
}
This seems very strange too : In case of a RX spike, we reset card ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists