1. 21 3月, 2010 5 次提交
  2. 20 3月, 2010 13 次提交
  3. 19 3月, 2010 10 次提交
  4. 18 3月, 2010 2 次提交
  5. 17 3月, 2010 10 次提交
    • M
      vhost: fix interrupt mitigation with raw sockets · 0e255572
      Michael S. Tsirkin 提交于
      A thinko in code means we never trigger interrupt
      mitigation. Fix this.
      Reported-by: NJuan Quintela <quintela@redhat.com>
      Reported-by: NUnai Uribarri <unai.uribarri@optenet.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      0e255572
    • D
      bridge: Make first arg to deliver_clone const. · 87faf3cc
      David S. Miller 提交于
      Otherwise we get a warning from the call in br_forward().
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87faf3cc
    • Y
      bridge br_multicast: Don't refer to BR_INPUT_SKB_CB(skb)->mrouters_only without IGMP snooping. · 32dec5dd
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      Without CONFIG_BRIDGE_IGMP_SNOOPING,
      BR_INPUT_SKB_CB(skb)->mrouters_only is not appropriately
      initialized, so we can see garbage.
      
      A clear option to fix this is to set it even without that
      config, but we cannot optimize out the branch.
      
      Let's introduce a macro that returns value of mrouters_only
      and let it return 0 without CONFIG_BRIDGE_IGMP_SNOOPING.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32dec5dd
    • V
      route: Fix caught BUG_ON during rt_secret_rebuild_oneshot() · 858a18a6
      Vitaliy Gusev 提交于
      route: Fix caught BUG_ON during rt_secret_rebuild_oneshot()
      
      Call rt_secret_rebuild can cause BUG_ON(timer_pending(&net->ipv4.rt_secret_timer)) in
      add_timer as there is not any synchronization for call rt_secret_rebuild_oneshot()
      for the same net namespace.
      
      Also this issue affects to rt_secret_reschedule().
      
      Thus use mod_timer enstead.
      Signed-off-by: NVitaliy Gusev <vgusev@openvz.org>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      858a18a6
    • Y
    • Y
    • J
      NET: netpoll, fix potential NULL ptr dereference · 21edbb22
      Jiri Slaby 提交于
      Stanse found that one error path in netpoll_setup dereferences npinfo
      even though it is NULL. Avoid that by adding new label and go to that
      instead.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: Daniel Borkmann <danborkmann@googlemail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Acked-by: chavey@google.com
      Acked-by: NMatt Mackall <mpm@selenic.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21edbb22
    • N
      tipc: fix lockdep warning on address assignment · a2f46ee1
      Neil Horman 提交于
      So in the forward porting of various tipc packages, I was constantly
      getting this lockdep warning everytime I used tipc-config to set a network
      address for the protocol:
      
      [ INFO: possible circular locking dependency detected ]
      2.6.33 #1
      tipc-config/1326 is trying to acquire lock:
      (ref_table_lock){+.-...}, at: [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      
      but task is already holding lock:
      (&(&entry->lock)->rlock#2){+.-...}, at: [<ffffffffa03150d5>] tipc_ref_lock+0x43/0x63 [tipc]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&(&entry->lock)->rlock#2){+.-...}:
      [<ffffffff8107b508>] __lock_acquire+0xb67/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff8145471e>] _raw_spin_lock_bh+0x3b/0x6e
      [<ffffffffa03152b1>] tipc_ref_acquire+0xe8/0x11b [tipc]
      [<ffffffffa031433f>] tipc_createport_raw+0x78/0x1b9 [tipc]
      [<ffffffffa031450b>] tipc_createport+0x8b/0x125 [tipc]
      [<ffffffffa030f221>] tipc_subscr_start+0xce/0x126 [tipc]
      [<ffffffffa0308fb2>] process_signal_queue+0x47/0x7d [tipc]
      [<ffffffff81053e0c>] tasklet_action+0x8c/0xf4
      [<ffffffff81054bd8>] __do_softirq+0xf8/0x1cd
      [<ffffffff8100aadc>] call_softirq+0x1c/0x30
      [<ffffffff810549f4>] _local_bh_enable_ip+0xb8/0xd7
      [<ffffffff81054a21>] local_bh_enable_ip+0xe/0x10
      [<ffffffff81454d31>] _raw_spin_unlock_bh+0x34/0x39
      [<ffffffffa0308eb8>] spin_unlock_bh.clone.0+0x15/0x17 [tipc]
      [<ffffffffa0308f47>] tipc_k_signal+0x8d/0xb1 [tipc]
      [<ffffffffa0308dd9>] tipc_core_start+0x8a/0xad [tipc]
      [<ffffffffa01b1087>] 0xffffffffa01b1087
      [<ffffffff8100207d>] do_one_initcall+0x72/0x18a
      [<ffffffff810872fb>] sys_init_module+0xd8/0x23a
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      -> #0 (ref_table_lock){+.-...}:
      [<ffffffff8107b3b2>] __lock_acquire+0xa11/0xd0f
      [<ffffffff8107b78c>] lock_acquire+0xdc/0x102
      [<ffffffff81454836>] _raw_write_lock_bh+0x3b/0x6e
      [<ffffffffa0315148>] tipc_ref_discard+0x53/0xd4 [tipc]
      [<ffffffffa03141ee>] tipc_deleteport+0x40/0x119 [tipc]
      [<ffffffffa0316e35>] release+0xeb/0x137 [tipc]
      [<ffffffff8139dbf4>] sock_release+0x1f/0x6f
      [<ffffffff8139dc6b>] sock_close+0x27/0x2b
      [<ffffffff811116f6>] __fput+0x12a/0x1df
      [<ffffffff811117c5>] fput+0x1a/0x1c
      [<ffffffff8110e49b>] filp_close+0x68/0x72
      [<ffffffff8110e552>] sys_close+0xad/0xe7
      [<ffffffff81009b42>] system_call_fastpath+0x16/0x1b
      
      Finally decided I should fix this.  Its a straightforward inversion,
      tipc_ref_acquire takes two locks in this order:
      ref_table_lock
      entry->lock
      
      while tipc_deleteport takes them in this order:
      entry->lock (via tipc_port_lock())
      ref_table_lock (via tipc_ref_discard())
      
      when the same entry is referenced, we get the above warning.  The fix is equally
      straightforward.  Theres no real relation between the entry->lock and the
      ref_table_lock (they just are needed at the same time), so move the entry->lock
      aquisition in tipc_ref_acquire down, after we unlock ref_table_lock (this is
      safe since the ref_table_lock guards changes to the reference table, and we've
      already claimed a slot there.  I've tested the below fix and confirmed that it
      clears up the lockdep issue
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Allan Stephens <allan.stephens@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a2f46ee1
    • J
      l2tp: Fix UDP socket reference count bugs in the pppol2tp driver · c3259c8a
      James Chapman 提交于
      This patch fixes UDP socket refcnt bugs in the pppol2tp driver.
      
      A bug can cause a kernel stack trace when a tunnel socket is closed.
      
      A way to reproduce the issue is to prepare the UDP socket for L2TP (by
      opening a tunnel pppol2tp socket) and then close it before any L2TP
      sessions are added to it. The sequence is
      
      Create UDP socket
      Create tunnel pppol2tp socket to prepare UDP socket for L2TP
        pppol2tp_connect: session_id=0, peer_session_id=0
      L2TP SCCRP control frame received (tunnel_id==0)
        pppol2tp_recv_core: sock_hold()
        pppol2tp_recv_core: sock_put
      L2TP ZLB control frame received (tunnel_id=nnn)
        pppol2tp_recv_core: sock_hold()
        pppol2tp_recv_core: sock_put
      Close tunnel management socket
        pppol2tp_release: session_id=0, peer_session_id=0
      Close UDP socket
        udp_lib_close: BUG
      
      The addition of sock_hold() in pppol2tp_connect() solves the problem.
      
      For data frames, two sock_put() calls were added to plug a refcnt leak
      per received data frame. The ref that is grabbed at the top of
      pppol2tp_recv_core() must always be released, but this wasn't done for
      accepted data frames or data frames discarded because of bad UDP
      checksums. This leak meant that any UDP socket that had passed L2TP
      data traffic (i.e. L2TP data frames, not just L2TP control frames)
      using pppol2tp would not be released by the kernel.
      
      WARNING: at include/net/sock.h:435 udp_lib_unhash+0x117/0x120()
      Pid: 1086, comm: openl2tpd Not tainted 2.6.33-rc1 #8
      Call Trace:
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c101b871>] ? warn_slowpath_common+0x71/0xd0
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c101b8e3>] ? warn_slowpath_null+0x13/0x20
       [<c119e9b7>] ? udp_lib_unhash+0x117/0x120
       [<c11598a7>] ? sk_common_release+0x17/0x90
       [<c11a5e33>] ? inet_release+0x33/0x60
       [<c11577b0>] ? sock_release+0x10/0x60
       [<c115780f>] ? sock_close+0xf/0x30
       [<c106e542>] ? __fput+0x52/0x150
       [<c106b68e>] ? filp_close+0x3e/0x70
       [<c101d2e2>] ? put_files_struct+0x62/0xb0
       [<c101eaf7>] ? do_exit+0x5e7/0x650
       [<c1081623>] ? mntput_no_expire+0x13/0x70
       [<c106b68e>] ? filp_close+0x3e/0x70
       [<c101eb8a>] ? do_group_exit+0x2a/0x70
       [<c101ebe1>] ? sys_exit_group+0x11/0x20
       [<c10029b0>] ? sysenter_do_call+0x12/0x26
      Signed-off-by: NJames Chapman <jchapman@katalix.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3259c8a
    • S
      smsc95xx: wait for PHY to complete reset during init · db443c44
      Steve Glendinning 提交于
      This patch ensures the PHY correctly completes its reset before
      setting register values.
      Signed-off-by: NSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db443c44