lkml.org 
[lkml]   [2010]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.34-rc1: rcu lockdep bug?
    On Fri, Mar 12, 2010 at 02:37:38PM +0100, Eric Dumazet wrote:
    >Le vendredi 12 mars 2010 à 21:11 +0800, Américo Wang a écrit :
    >
    >> Oh, but lockdep complains about rcu_read_lock(), it said
    >> rcu_read_lock() can't be used in softirq context.
    >>
    >> Am I missing something?
    >
    >Well, lockdep might be dumb, I dont know...
    >
    >I suggest you read rcu_read_lock_bh kernel doc :
    >
    >/**
    > * rcu_read_lock_bh - mark the beginning of a softirq-only RCU critical
    >section
    > *
    > * This is equivalent of rcu_read_lock(), but to be used when updates
    > * are being done using call_rcu_bh(). Since call_rcu_bh() callbacks
    > * consider completion of a softirq handler to be a quiescent state,
    > * a process in RCU read-side critical section must be protected by
    > * disabling softirqs. Read-side critical sections in interrupt context
    > * can use just rcu_read_lock().
    > *
    > */
    >
    >
    >Last sentence being perfect :
    >
    >Read-side critical sections in interrupt context
    >can use just rcu_read_lock().
    >

    Yeah, right, then it is more likely to be a bug of rcu lockdep.
    Paul is looking at it.

    Thanks!
    --
    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-13 06:33    [W:0.043 / U:2.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site