lkml.org 
[lkml]   [2010]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.6.34-rc1: rcu lockdep bug?
    From
    Date
    Le lundi 15 mars 2010 à 18:12 +0800, Américo Wang a écrit :
    > On Mon, Mar 15, 2010 at 6:04 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
    > > Le lundi 15 mars 2010 à 17:39 +0800, Américo Wang a écrit :
    > >
    > >>
    > >> Ok, I think I found what lockdep really complains about, it is that we took
    > >> spin_lock in netpoll_poll_lock() which is in hardirq-enabled environment,
    > >> later, we took another spin_lock with spin_lock_irqsave() in netpoll_rx(),
    > >> so lockdep thought we broke the locking rule.
    > >>
    > >> I don't know why netpoll_rx() needs irq disabled, it looks like that no one
    > >> takes rx_lock in hardirq context. So can we use spin_lock(&rx_lock)
    > >> instead? Or am I missing something here? Eric? David?
    > >
    > > I am a bit lost.
    > >
    > > Could you give the complete picture, because I cannot find it in my
    > > netdev archives.
    > >
    >
    > Sure, sorry for this.
    >
    > Here is the whole thread:
    >
    > http://lkml.org/lkml/2010/3/11/100

    OK thanks

    netpoll_rx() can be called from hard irqs (netif_rx()), so rx_lock
    definitly needs irq care.

    netpoll_poll_lock() does take a spinlock with irq enabled, but its not
    rx_lock, its napi->poll_lock.

    I dont see what could be the problem, is it reproductible with vanilla
    kernel ?


    --
    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/

    \
     
     \ /
      Last update: 2010-03-15 11:43    [W:0.024 / U:1.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site