Bug 15781
| Summary: | invoked rcu_dereference_check() without protection in net/netfilter/nf_log.c:55 | ||
|---|---|---|---|
| Product: | Networking | Reporter: | Christian Casteyde (casteyde.christian) |
| Component: | Netfilter/Iptables | Assignee: | networking_netfilter-iptables (networking_netfilter-iptables) |
| Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.34-rc3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
netfilter: remove invalid rcu_dereference() calls
work around lockdep warning |
||
Created attachment 26020 [details]
netfilter: remove invalid rcu_dereference() calls
The attached patches fixes the warnings. Its already queued for upstream submission.
Still not correct it seems.
I've tested your patch on -rc4 and got the following warning (not the same, but still in netfilter):
EXT3-fs (hda3): using internal journal
EXT3-fs (hda3): mounted filesystem with writeback data mode
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
include/net/netfilter/nf_conntrack_l3proto.h:92 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
2 locks held by iptables/3197:
#0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff8149bd8c>] ip_setsockopt+0x7c/0xa0
#1: (&xt[i].mutex){+.+.+.}, at: [<ffffffff8148a5fe>] xt_find_table_lock+0x3e/0x110
stack backtrace:
Pid: 3197, comm: iptables Not tainted 2.6.34-rc4 #2
Call Trace:
[<ffffffff8105e2e8>] lockdep_rcu_dereference+0xb8/0xc0
[<ffffffff8147fb3b>] nf_ct_l3proto_module_put+0x6b/0x70
[<ffffffff8148d891>] state_mt_destroy+0x11/0x20
[<ffffffff814d3baf>] cleanup_match+0x2f/0x50
[<ffffffff814d3c63>] cleanup_entry+0x33/0x90
[<ffffffff814d5653>] ? __do_replace+0x1a3/0x210
[<ffffffff814d564c>] __do_replace+0x19c/0x210
[<ffffffff814d651a>] do_ipt_set_ctl+0x16a/0x1b0
[<ffffffff8147a610>] nf_sockopt+0x60/0xa0
[<ffffffff8147a68c>] nf_setsockopt+0x1c/0x20
[<ffffffff8149bda2>] ip_setsockopt+0x92/0xa0
[<ffffffff814b80a1>] raw_setsockopt+0x11/0x30
[<ffffffff8145039f>] sock_common_setsockopt+0xf/0x20
[<ffffffff8144e13c>] sys_setsockopt+0x6c/0xc0
[<ffffffff81002468>] system_call_fastpath+0x16/0x1b
It occurs a litte later, while init is triggering udev events.
Update: Still present in 2.6.34-rc5. Update: Still present in 2.6.34-rc6. Created attachment 26194 [details]
work around lockdep warning
Could you give this patch a try please?
With both patches from comment #1 and comment #5, the warning doesn't appear anymore. Thanks Closing. |
Acer Aspire 1511LMi Athlon 64 3000 in 64bits mode 1.2 GB RAM Bluewhite 64 13 (64 bits port of Slackware) Since 2.6.34-rc3, I got the following warning: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- net/netfilter/nf_log.c:55 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 swapper/1: #0: (nf_log_mutex){+.+...}, at: [<ffffffff814794f7>] nf_log_register+0x57/0x130 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.34-rc3 #3 Call Trace: [<ffffffff8105e058>] lockdep_rcu_dereference+0xb8/0xc0 [<ffffffff81ac8349>] ? log_tg_init+0x0/0x29 [<ffffffff814795b0>] nf_log_register+0x110/0x130 [<ffffffff81ac8349>] ? log_tg_init+0x0/0x29 [<ffffffff81ac836e>] log_tg_init+0x25/0x29 [<ffffffff810001c7>] do_one_initcall+0x37/0x190 [<ffffffff81a9e5bd>] kernel_init+0xe0/0x16c [<ffffffff815a3152>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81003074>] kernel_thread_helper+0x4/0x10 [<ffffffff815a40fe>] ? restore_args+0x0/0x30 [<ffffffff81a9e4dd>] ? kernel_init+0x0/0x16c [<ffffffff81003070>] ? kernel_thread_helper+0x0/0x10 It didn't appeared in -rc1, however I got another similar warning with -rc1 which seems to have been fixed since (see https://bugzilla.kernel.org/show_bug.cgi?id=15510#c0). I've therefore reported this one in a separate report, since finally I think it's a different problem. I don't know if it was present in -rc2.