1. 27 8月, 2008 1 次提交
    • Z
      lockdep: fix invalid list_del_rcu in zap_class · 74870172
      Zhu Yi 提交于
      The problem is found during iwlagn driver testing on
      v2.6.27-rc4-176-gb8e6c91c kernel, but it turns out to be a lockdep bug.
      In our testing, we frequently load and unload the iwlagn driver
      (>50 times). Then the MAX_STACK_TRACE_ENTRIES is reached (expected
      behaviour?). The error message with the call trace is as below.
      
      BUG: MAX_STACK_TRACE_ENTRIES too low!
      turning off the locking correctness validator.
      Pid: 4895, comm: iwlagn Not tainted 2.6.27-rc4 #13
      
      Call Trace:
       [<ffffffff81014aa1>] save_stack_trace+0x22/0x3e
       [<ffffffff8105390a>] save_trace+0x8b/0x91
       [<ffffffff81054e60>] mark_lock+0x1b0/0x8fa
       [<ffffffff81056f71>] __lock_acquire+0x5b9/0x716
       [<ffffffffa00d818a>] ieee80211_sta_work+0x0/0x6ea [mac80211]
       [<ffffffff81057120>] lock_acquire+0x52/0x6b
       [<ffffffff81045f0e>] run_workqueue+0x97/0x1ed
       [<ffffffff81045f5e>] run_workqueue+0xe7/0x1ed
       [<ffffffff81045f0e>] run_workqueue+0x97/0x1ed
       [<ffffffff81046ae4>] worker_thread+0xd8/0xe3
       [<ffffffff81049503>] autoremove_wake_function+0x0/0x2e
       [<ffffffff81046a0c>] worker_thread+0x0/0xe3
       [<ffffffff810493ec>] kthread+0x47/0x73
       [<ffffffff8128e3ab>] trace_hardirqs_on_thunk+0x3a/0x3f
       [<ffffffff8100cea9>] child_rip+0xa/0x11
       [<ffffffff8100c4df>] restore_args+0x0/0x30
       [<ffffffff810316e1>] finish_task_switch+0x0/0xcc
       [<ffffffff810493a5>] kthread+0x0/0x73
       [<ffffffff8100ce9f>] child_rip+0x0/0x11
      
      Although the above is harmless, when the ilwagn module is removed
      later lockdep will trigger a kernel oops as below.
      
      BUG: unable to handle kernel NULL pointer dereference at
      0000000000000008
      IP: [<ffffffff810531e1>] zap_class+0x24/0x82
      PGD 73128067 PUD 7448c067 PMD 0
      Oops: 0002 [1] SMP
      CPU 0
      Modules linked in: rfcomm l2cap bluetooth autofs4 sunrpc
      nf_conntrack_ipv6 xt_state nf_conntrack xt_tcpudp ip6t_ipv6header
      ip6t_REJECT ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand
      acpi_cpufreq dm_mirror dm_log dm_multipath dm_mod snd_hda_intel sr_mod
      snd_seq_dummy snd_seq_oss snd_seq_midi_event battery snd_seq
      snd_seq_device cdrom button snd_pcm_oss snd_mixer_oss snd_pcm
      snd_timer snd_page_alloc e1000e snd_hwdep sg iTCO_wdt
      iTCO_vendor_support ac pcspkr i2c_i801 i2c_core snd soundcore video
      output ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache
      uhci_hcd ohci_hcd ehci_hcd [last unloaded: mac80211]
      Pid: 4941, comm: modprobe Not tainted 2.6.27-rc4 #10
      RIP: 0010:[<ffffffff810531e1>]  [<ffffffff810531e1>]
      zap_class+0x24/0x82
      RSP: 0000:ffff88007bcb3eb0  EFLAGS: 00010046
      RAX: 0000000000068ee8 RBX: ffffffff8192a0a0 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: 0000000000001dfb RDI: ffffffff816e70b0
      RBP: ffffffffa00cd000 R08: ffffffff816818f8 R09: ffff88007c923558
      R10: ffffe20002ad2408 R11: ffffffff811028ec R12: ffffffff8192a0a0
      R13: 000000000002bd90 R14: 0000000000000000 R15: 0000000000000296
      FS:  00007f9d1cee56f0(0000) GS:ffffffff814a58c0(0000)
      knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000000008 CR3: 0000000073047000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process modprobe (pid: 4941, threadinfo ffff88007bcb2000, task
      ffff8800758d1fc0)
      Stack:  ffffffff81057376 0000000000000000 ffffffffa00f7b00
      0000000000000000
       0000000000000080 0000000000618278 00007fff24f16720 0000000000000000
       ffffffff8105d37a ffffffffa00f7b00 ffffffff8105d591 313132303863616d
      Call Trace:
       [<ffffffff81057376>] ? lockdep_free_key_range+0x61/0xf5
       [<ffffffff8105d37a>] ? free_module+0xd4/0xe4
       [<ffffffff8105d591>] ? sys_delete_module+0x1de/0x1f9
       [<ffffffff8106dbfa>] ? audit_syscall_entry+0x12d/0x160
       [<ffffffff8100be2b>] ? system_call_fastpath+0x16/0x1b
      
      Code: b2 00 01 00 00 00 c3 31 f6 49 c7 c0 10 8a 61 81 eb 32 49 39 38
      75 26 48 98 48 6b c0 38 48 8b 90 08 8a 61 81 48 8b 88 00 8a 61 81 <48>
      89 51 08 48 89 0a 48 c7 80 08 8a 61 81 00 02 20 00 48 ff c6
      RIP  [<ffffffff810531e1>] zap_class+0x24/0x82
       RSP <ffff88007bcb3eb0>
      CR2: 0000000000000008
      ---[ end trace a1297e0c4abb0f2e ]---
      
      The root cause for this oops is in add_lock_to_list() when
      save_trace() fails due to MAX_STACK_TRACE_ENTRIES is reached,
      entry->class is assigned but entry is never added into any lock list.
      This makes the list_del_rcu() in zap_class() oops later when the
      module is unloaded. This patch fixes the problem by assigning
      entry->class after save_trace() returns success.
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      74870172
  2. 26 8月, 2008 2 次提交
    • J
      lockstat: repair erronous contention statistics · 04148b73
      Joe Korty 提交于
      Fix bad contention counting in /proc/lock_stat.
      
      /proc/lockstat tries to gather per-ip contention
      statistics per-lock.  This was failing due to
      a garbage per-ip index selector being used.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      04148b73
    • J
      lockstat: fix numerical output rounding error · 2189459d
      Joe Korty 提交于
      Fix rounding error in /proc/lock_stat numerical output.
      
      On occasion the two digit fractional part contains the three
      digit value '100'.  This is due to a bug in the rounding algorithm
      which pushes values in the range '95..99' to '100' rather than
      to '00' + an increment to the integer part.  For example,
      
      	- 123456.100      old display
      	+ 123457.00	  new display
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2189459d
  3. 24 8月, 2008 3 次提交
  4. 23 8月, 2008 2 次提交
    • S
      ipv6: protocol for address routes · f410a1fb
      Stephen Hemminger 提交于
      This fixes a problem spotted with zebra, but not sure if it is
      necessary a kernel problem.  With IPV6 when an address is added to an
      interface, Zebra creates a duplicate RIB entry, one as a connected
      route, and other as a kernel route.
      
      When an address is added to an interface the RTN_NEWADDR message
      causes Zebra to create a connected route. In IPV4 when an address is
      added to an interface a RTN_NEWROUTE message is set to user space with
      the protocol RTPROT_KERNEL. Zebra ignores these messages, because it
      already has the connected route.
      
      The problem is that route created in IPV6 has route protocol ==
      RTPROT_BOOT.  Was this a design decision or a bug? This fixes it. Same
      patch applies to both net-2.6 and stable.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f410a1fb
    • D
      icmp: icmp_sk() should not use smp_processor_id() in preemptible code · fdc0bde9
      Denis V. Lunev 提交于
      Pass namespace into icmp_xmit_lock, obtain socket inside and return
      it as a result for caller.
      
      Thanks Alexey Dobryan for this report:
      
      Steps to reproduce:
      
      	CONFIG_PREEMPT=y
      	CONFIG_DEBUG_PREEMPT=y
      	tracepath <something>
      
      BUG: using smp_processor_id() in preemptible [00000000] code: tracepath/3205
      caller is icmp_sk+0x15/0x30
      Pid: 3205, comm: tracepath Not tainted 2.6.27-rc4 #1
      
      Call Trace:
       [<ffffffff8031af14>] debug_smp_processor_id+0xe4/0xf0
       [<ffffffff80409405>] icmp_sk+0x15/0x30
       [<ffffffff8040a17b>] icmp_send+0x4b/0x3f0
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8023a475>] ? local_bh_enable_ip+0x95/0x110
       [<ffffffff804285b9>] ? _spin_unlock_bh+0x39/0x40
       [<ffffffff8025a26c>] ? mark_held_locks+0x4c/0x90
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff803e91b4>] ip_fragment+0x8d4/0x900
       [<ffffffff803e7030>] ? ip_finish_output2+0x0/0x290
       [<ffffffff803e91e0>] ? ip_finish_output+0x0/0x60
       [<ffffffff803e6650>] ? dst_output+0x0/0x10
       [<ffffffff803e922c>] ip_finish_output+0x4c/0x60
       [<ffffffff803e92e3>] ip_output+0xa3/0xf0
       [<ffffffff803e68d0>] ip_local_out+0x20/0x30
       [<ffffffff803e753f>] ip_push_pending_frames+0x27f/0x400
       [<ffffffff80406313>] udp_push_pending_frames+0x233/0x3d0
       [<ffffffff804067d1>] udp_sendmsg+0x321/0x6f0
       [<ffffffff8040d155>] inet_sendmsg+0x45/0x80
       [<ffffffff803b967f>] sock_sendmsg+0xdf/0x110
       [<ffffffff8024a100>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff80257ce5>] ? validate_chain+0x415/0x1010
       [<ffffffff8027dc10>] ? __do_fault+0x140/0x450
       [<ffffffff802597d0>] ? __lock_acquire+0x260/0x590
       [<ffffffff803b9e55>] ? sockfd_lookup_light+0x45/0x80
       [<ffffffff803ba50a>] sys_sendto+0xea/0x120
       [<ffffffff80428e42>] ? _spin_unlock_irqrestore+0x42/0x80
       [<ffffffff803134bc>] ? __up_read+0x4c/0xb0
       [<ffffffff8024e0c6>] ? up_read+0x26/0x30
       [<ffffffff8020b8bb>] system_call_fastpath+0x16/0x1b
      
      icmp6_sk() is similar.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fdc0bde9
  5. 22 8月, 2008 32 次提交