[ovs-dev] rcu dereference warnings

Jesse Gross jesse at nicira.com
Mon Dec 6 19:09:46 UTC 2010


On Mon, Dec 6, 2010 at 10:41 AM, Ben Pfaff <blp at nicira.com> wrote:
> I get the following warning at boot now on 2.6.36:
>
>    ===================================================
>    [ INFO: suspicious rcu_dereference_check() usage. ]
>    ---------------------------------------------------
>    /home/blp/db/_build/datapath/linux-2.6/vport-netdev.c:282 invoked rcu_dereference_check() without protection!
>
>    other info that might help us debug this:
>
>
>    rcu_scheduler_active = 1, debug_locks = 0
>    1 lock held by insmod/569:
>     #0:  (rtnl_mutex){+.+.+.}, at: [<c121f636>] rtnl_lock+0xf/0x11
>
>    stack backtrace:
>    Pid: 569, comm: insmod Not tainted 2.6.36+ #20
>    Call Trace:
>     [<c12c9770>] ? printk+0xf/0x17
>     [<c104e743>] lockdep_rcu_dereference+0x7d/0x86
>     [<c8ac81b9>] netdev_get_vport+0x37/0x81 [openvswitch_mod]
>     [<c8ac2ca7>] dp_device_event+0x2b/0xa4 [openvswitch_mod]
>     [<c12175aa>] register_netdevice_notifier+0x54/0x14d
>     [<c8ad0035>] dp_init+0x35/0x6d [openvswitch_mod]
>     [<c1001076>] do_one_initcall+0x71/0x118
>     [<c8ad0000>] ? dp_init+0x0/0x6d [openvswitch_mod]
>     [<c105a396>] sys_init_module+0xcd6/0xe64
>     [<c12cbc51>] syscall_call+0x7/0xb
>
> I think that it is a false alarm because the RTNL lock is held, which
> should prevent the vport from being destroyed under us.  Any opinion on
> the best way to suppress the warning or, if it's a real problem, to fix
> it?  We can't just do rcu_read_lock()/unlock() around this function
> because it takes mutexes.

Yes, it's a false alarm.

I think the right solution is to backport and use
rcu_dereference_rtnl() from 2.6.37 (I know it's not released yet but
it is very nice functionality and I'm pretty sure it is going to be
part of the kernel in the near future).  This will check that we hold
either RCU read lock or RTNL, which is what we need here.

I have a branch of cleanups for sparse warnings and I've been adding
usage of both this and rtnl_dereference() (which makes sparse not
complain about pointers decorated with __rcu that are accessed
directly under RTNL).  I haven't done the backporting or dealt with
issues like this yet though.




More information about the dev mailing list