Skip to contentSkip to conversation

New: SMP BUG in __nf_conntrack_find

Bugme-new Andrew Morton 1 participant 1 message Feb 25, 2008 1 message not in the archive

Subsystems (2)
Networking Network drivers
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author
#1 lore raw
Quoted 61 lines · On Mon, 25 Feb 2008 10:44:08 -0800 (PST) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=10097

           Summary: SMP BUG in __nf_conntrack_find
           Product: Networking
           Version: 2.5
     KernelVersion: 2.6.25-rc3
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Netfilter/Iptables
        AssignedTo: [email protected]
        ReportedBy: [email protected]

Latest working kernel version: 2.6.24.2
Earliest failing kernel version: 2.6.24-rc3 (not checked before)
Distribution: Bluewhite64
Hardware Environment: Athlon X2 4200

Software Environment:
samba 3.0, 2.6.25-rc3 kernel + HR + tickless + kernel SMP debugging

Problem Description:
The Samba smbd daemon triggers regularly the following BUG with 2.6.25-rc3:

BUG: using smp_processor_id() in preemptible [00000000] code: nmbd/3167
caller is __nf_conntrack_find+0x119/0x150

Pid: 3167, comm: nmbd Not tainted 2.6.25-rc3 #1

Call Trace:
 [<ffffffff8038f3f4>] debug_smp_processor_id+0xc4/0xd0
 [<ffffffff80555d79>] __nf_conntrack_find+0x119/0x150
 [<ffffffff80555dc9>] nf_conntrack_find_get+0x19/0x80
 [<ffffffff80556914>] nf_conntrack_in+0x1a4/0x5a0
 [<ffffffff8020bd33>] ? restore_args+0x0/0x30
 [<ffffffff8059d596>] ipv4_conntrack_local+0x66/0x70
 [<ffffffff80554362>] nf_iterate+0x62/0xa0
 [<ffffffff80567050>] ? dst_output+0x0/0x10
 [<ffffffff80554406>] nf_hook_slow+0x66/0xe0
 [<ffffffff80567050>] ? dst_output+0x0/0x10
 [<ffffffff80568825>] __ip_local_out+0xa5/0xb0
 [<ffffffff80568841>] ip_local_out+0x11/0x30
 [<ffffffff80568ac1>] ip_push_pending_frames+0x261/0x3e0
 [<ffffffff80587153>] udp_push_pending_frames+0x233/0x3d0
 [<ffffffff8058860f>] udp_sendmsg+0x30f/0x710
 [<ffffffff802328b0>] ? default_wake_function+0x0/0x10
 [<ffffffff8058f895>] inet_sendmsg+0x45/0x80
 [<ffffffff80531fcf>] sock_sendmsg+0xdf/0x110
 [<ffffffff80251270>] ? autoremove_wake_function+0x0/0x40
 [<ffffffff802374c7>] ? hrtick_resched+0x77/0x90
 [<ffffffff8025e2b5>] ? trace_hardirqs_on+0xd5/0x160
 [<ffffffff80531735>] ? sockfd_lookup_light+0x45/0x80
 [<ffffffff805323da>] sys_sendto+0xea/0x120
 [<ffffffff80626bcb>] ? _spin_unlock_irq+0x2b/0x60
 [<ffffffff8025e2b5>] ? trace_hardirqs_on+0xd5/0x160
 [<ffffffff80626bd6>] ? _spin_unlock_irq+0x36/0x60
 [<ffffffff8020b6db>] system_call_after_swapgs+0x7b/0x80
Quoted 4 lines

Steps to reproduce:
Start smbd with the forementionned kernel instrumented for SMP and kernel debugging and hr + tickless enabled.

Presumably this is in NF_CT_STAT_INC(). I wonder what caused it to start happening.

Guys, this probably means that the developers who tested this change aren't enabling the debug options which all kernel developers _should_ be enabling when "testing" their code! Documentation/SubmitChecklist has a handy list.

Should NF_CT_STAT_INC() be using local_inc()?