1. 07 Oct, 2008 5 commits
    • Daniele Lacamera's avatar
      tcp: Fix tcp_hybla zero congestion window growth with small rho and large cwnd. · 9d2c27e1
      Daniele Lacamera authored
      Because of rounding, in certain conditions, i.e. when in congestion
      avoidance state rho is smaller than 1/128 of the current cwnd, TCP
      Hybla congestion control starves and the cwnd is kept constant
      forever.
      
      This patch forces an increment by one segment after #send_cwnd calls
      without increments(newreno behavior).
      Signed-off-by: default avatarDaniele Lacamera <root@danielinux.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d2c27e1
    • Herbert Xu's avatar
      net: Fix netdev_run_todo dead-lock · 58ec3b4d
      Herbert Xu authored
      Benjamin Thery tracked down a bug that explains many instances
      of the error
      
      unregister_netdevice: waiting for %s to become free. Usage count = %d
      
      It turns out that netdev_run_todo can dead-lock with itself if
      a second instance of it is run in a thread that will then free
      a reference to the device waited on by the first instance.
      
      The problem is really quite silly.  We were trying to create
      parallelism where none was required.  As netdev_run_todo always
      follows a RTNL section, and that todo tasks can only be added
      with the RTNL held, by definition you should only need to wait
      for the very ones that you've added and be done with it.
      
      There is no need for a second mutex or spinlock.
      
      This is exactly what the following patch does.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58ec3b4d
    • David S. Miller's avatar
    • Ali Saidi's avatar
      tcp: Fix possible double-ack w/ user dma · 53240c20
      Ali Saidi authored
      From: Ali Saidi <saidi@engin.umich.edu>
      
      When TCP receive copy offload is enabled it's possible that
      tcp_rcv_established() will cause two acks to be sent for a single
      packet. In the case that a tcp_dma_early_copy() is successful,
      copied_early is set to true which causes tcp_cleanup_rbuf() to be
      called early which can send an ack. Further along in
      tcp_rcv_established(), __tcp_ack_snd_check() is called and will
      schedule a delayed ACK. If no packets are processed before the delayed
      ack timer expires the packet will be acked twice.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53240c20
    • Patrick McHardy's avatar
      net: only invoke dev->change_rx_flags when device is UP · b6c40d68
      Patrick McHardy authored
      Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
      device down that is in promiscous mode:
      
      When the VLAN device is set down, the promiscous count on the real
      device is decremented by one by vlan_dev_stop(). When removing the
      promiscous flag from the VLAN device afterwards, the promiscous
      count on the real device is decremented a second time by the
      vlan_change_rx_flags() callback.
      
      The root cause for this is that the ->change_rx_flags() callback is
      invoked while the device is down. The synchronization is meant to mirror
      the behaviour of the ->set_rx_mode callbacks, meaning the ->open function
      is responsible for doing a full sync on open, the ->close() function is
      responsible for doing full cleanup on ->stop() and ->change_rx_flags()
      is meant to do incremental changes while the device is UP.
      
      Only invoke ->change_rx_flags() while the device is UP to provide the
      intended behaviour.
      Tested-by: default avatarJesper Dangaard Brouer <jdb@comx.dk>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b6c40d68
  2. 06 Oct, 2008 6 commits
  3. 01 Oct, 2008 4 commits
    • Timo Teras's avatar
      af_key: Free dumping state on socket close · 05238204
      Timo Teras authored
      Fix a xfrm_{state,policy}_walk leak if pfkey socket is closed while
      dumping is on-going.
      Signed-off-by: default avatarTimo Teras <timo.teras@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05238204
    • Arnaud Ebalard's avatar
      XFRM,IPv6: initialize ip6_dst_blackhole_ops.kmem_cachep · 5dc121e9
      Arnaud Ebalard authored
      ip6_dst_blackhole_ops.kmem_cachep is not expected to be NULL (i.e. to
      be initialized) when dst_alloc() is called from ip6_dst_blackhole().
      Otherwise, it results in the following (xfrm_larval_drop is now set to
      1 by default):
      
      [   78.697642] Unable to handle kernel paging request for data at address 0x0000004c
      [   78.703449] Faulting instruction address: 0xc0097f54
      [   78.786896] Oops: Kernel access of bad area, sig: 11 [#1]
      [   78.792791] PowerMac
      [   78.798383] Modules linked in: btusb usbhid bluetooth b43 mac80211 cfg80211 ehci_hcd ohci_hcd sungem sungem_phy usbcore ssb
      [   78.804263] NIP: c0097f54 LR: c0334a28 CTR: c002d430
      [   78.809997] REGS: eef19ad0 TRAP: 0300   Not tainted  (2.6.27-rc5)
      [   78.815743] MSR: 00001032 <ME,IR,DR>  CR: 22242482  XER: 20000000
      [   78.821550] DAR: 0000004c, DSISR: 40000000
      [   78.827278] TASK = eef0df40[3035] 'mip6d' THREAD: eef18000
      [   78.827408] GPR00: 00001032 eef19b80 eef0df40 00000000 00008020 eef19c30 00000001 00000000
      [   78.833249] GPR08: eee5101c c05a5c10 ef9ad500 00000000 24242422 1005787c 00000000 1004f960
      [   78.839151] GPR16: 00000000 10024e90 10050040 48030018 0fe44150 00000000 00000000 eef19c30
      [   78.845046] GPR24: eef19e44 00000000 eef19bf8 efb37c14 eef19bf8 00008020 00009032 c0596064
      [   78.856671] NIP [c0097f54] kmem_cache_alloc+0x20/0x94
      [   78.862581] LR [c0334a28] dst_alloc+0x40/0xc4
      [   78.868451] Call Trace:
      [   78.874252] [eef19b80] [c03c1810] ip6_dst_lookup_tail+0x1c8/0x1dc (unreliable)
      [   78.880222] [eef19ba0] [c0334a28] dst_alloc+0x40/0xc4
      [   78.886164] [eef19bb0] [c03cd698] ip6_dst_blackhole+0x28/0x1cc
      [   78.892090] [eef19be0] [c03d9be8] rawv6_sendmsg+0x75c/0xc88
      [   78.897999] [eef19cb0] [c038bca4] inet_sendmsg+0x4c/0x78
      [   78.903907] [eef19cd0] [c03207c8] sock_sendmsg+0xac/0xe4
      [   78.909734] [eef19db0] [c03209e4] sys_sendmsg+0x1e4/0x2a0
      [   78.915540] [eef19f00] [c03220a8] sys_socketcall+0xfc/0x210
      [   78.921406] [eef19f40] [c0014b3c] ret_from_syscall+0x0/0x38
      [   78.927295] --- Exception: c01 at 0xfe2d730
      [   78.927297]     LR = 0xfe2d71c
      [   78.939019] Instruction dump:
      [   78.944835] 91640018 9144001c 900a0000 4bffff44 9421ffe0 7c0802a6 bf810010 7c9d2378
      [   78.950694] 90010024 7fc000a6 57c0045e 7c000124 <83e3004c> 8383005c 2f9f0000 419e0050
      [   78.956464] ---[ end trace 05fa1ed7972487a1 ]---
      
      As commented by Benjamin Thery, the bug was introduced by
      f2fc6a54, while adding network
      namespaces support to ipv6 routes.
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Acked-by: default avatarBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5dc121e9
    • Denis V. Lunev's avatar
      ipv6: NULL pointer dereferrence in tcp_v6_send_ack · 2a5b8275
      Denis V. Lunev authored
      The following actions are possible:
      tcp_v6_rcv
        skb->dev = NULL;
        tcp_v6_do_rcv
          tcp_v6_hnd_req
            tcp_check_req
              req->rsk_ops->send_ack == tcp_v6_send_ack
      
      So, skb->dev can be NULL in tcp_v6_send_ack. We must obtain namespace
      from dst entry.
      
      Thanks to Vitaliy Gusev <vgusev@openvz.org> for initial problem finding
      in IPv4 code.
      Signed-off-by: default avatarDenis V. Lunev <den@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a5b8275
    • Vitaliy Gusev's avatar
      tcp: Fix NULL dereference in tcp_4_send_ack() · 4dd7972d
      Vitaliy Gusev authored
      Fix NULL dereference in tcp_4_send_ack().
      
      As skb->dev is reset to NULL in tcp_v4_rcv() thus OOPS occurs:
      
      BUG: unable to handle kernel NULL pointer dereference at 00000000000004d0
      IP: [<ffffffff80498503>] tcp_v4_send_ack+0x203/0x250
      
      Stack:  ffff810005dbb000 ffff810015c8acc0 e77b2c6e5f861600 a01610802e90cb6d
       0a08010100000000 88afffff88afffff 0000000080762be8 0000000115c872e8
       0004122000000000 0000000000000001 ffffffff80762b88 0000000000000020
      Call Trace:
       <IRQ>  [<ffffffff80499c33>] tcp_v4_reqsk_send_ack+0x20/0x22
       [<ffffffff8049bce5>] tcp_check_req+0x108/0x14c
       [<ffffffff8047aaf7>] ? rt_intern_hash+0x322/0x33c
       [<ffffffff80499846>] tcp_v4_do_rcv+0x399/0x4ec
       [<ffffffff8045ce4b>] ? skb_checksum+0x4f/0x272
       [<ffffffff80485b74>] ? __inet_lookup_listener+0x14a/0x15c
       [<ffffffff8049babc>] tcp_v4_rcv+0x6a1/0x701
       [<ffffffff8047e739>] ip_local_deliver_finish+0x157/0x24a
       [<ffffffff8047ec9a>] ip_local_deliver+0x72/0x7c
       [<ffffffff8047e5bd>] ip_rcv_finish+0x38d/0x3b2
       [<ffffffff803d3548>] ? scsi_io_completion+0x19d/0x39e
       [<ffffffff8047ebe5>] ip_rcv+0x2a2/0x2e5
       [<ffffffff80462faa>] netif_receive_skb+0x293/0x303
       [<ffffffff80465a9b>] process_backlog+0x80/0xd0
       [<ffffffff802630b4>] ? __rcu_process_callbacks+0x125/0x1b4
       [<ffffffff8046560e>] net_rx_action+0xb9/0x17f
       [<ffffffff80234cc5>] __do_softirq+0xa3/0x164
       [<ffffffff8020c52c>] call_softirq+0x1c/0x28
       <EOI>  [<ffffffff8020de1c>] do_softirq+0x34/0x72
       [<ffffffff80234b8e>] local_bh_enable_ip+0x3f/0x50
       [<ffffffff804d43ca>] _spin_unlock_bh+0x12/0x14
       [<ffffffff804599cd>] release_sock+0xb8/0xc1
       [<ffffffff804a6f9a>] inet_stream_connect+0x146/0x25c
       [<ffffffff80243078>] ? autoremove_wake_function+0x0/0x38
       [<ffffffff8045751f>] sys_connect+0x68/0x8e
       [<ffffffff80291818>] ? fd_install+0x5f/0x68
       [<ffffffff80457784>] ? sock_map_fd+0x55/0x62
       [<ffffffff8020b39b>] system_call_after_swapgs+0x7b/0x80
      
      Code: 41 10 11 d0 83 d0 00 4d 85 ed 89 45 c0 c7 45 c4 08 00 00 00 74 07 41 8b 45 04 89 45 c8 48 8b 43 20 8b 4d b8 48 8d 55 b0 48 89 de <48> 8b 80 d0 04 00 00 48 8b b8 60 01 00 00 e8 20 ae fe ff 65 48
      RIP  [<ffffffff80498503>] tcp_v4_send_ack+0x203/0x250
       RSP <ffffffff80762b78>
      CR2: 00000000000004d0
      Signed-off-by: default avatarVitaliy Gusev <vgusev@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4dd7972d
  4. 30 Sep, 2008 3 commits
    • Wei Yongjun's avatar
      sctp: Fix kernel panic while process protocol violation parameter · ba016670
      Wei Yongjun authored
      Since call to function sctp_sf_abort_violation() need paramter 'arg' with
      'struct sctp_chunk' type, it will read the chunk type and chunk length from
      the chunk_hdr member of chunk. But call to sctp_sf_violation_paramlen()
      always with 'struct sctp_paramhdr' type's parameter, it will be passed to
      sctp_sf_abort_violation(). This may cause kernel panic.
      
         sctp_sf_violation_paramlen()
           |-- sctp_sf_abort_violation()
              |-- sctp_make_abort_violation()
      
      This patch fixed this problem. This patch also fix two place which called
      sctp_sf_violation_paramlen() with wrong paramter type.
      Signed-off-by: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ba016670
    • Heiko Carstens's avatar
      iucv: Fix mismerge again. · 8b122efd
      Heiko Carstens authored
      fb65a7c0 ("iucv: Fix bad merging.") fixed
      a merge error, but in a wrong way. We now end up with the bug below.
      This patch corrects the mismerge like it was intended.
      
      BUG: scheduling while atomic: swapper/1/0x00000000
      Modules linked in:
      CPU: 1 Not tainted 2.6.27-rc7-00094-gc0f4d6d4 #9
      Process swapper (pid: 1, task: 000000003fe7d988, ksp: 000000003fe838c0)
      0000000000000000 000000003fe839b8 0000000000000002 0000000000000000
             000000003fe83a58 000000003fe839d0 000000003fe839d0 0000000000390de6
             000000000058acd8 00000000000000d0 000000003fe7dcd8 0000000000000000
             000000000000000c 000000000000000d 0000000000000000 000000003fe83a28
             000000000039c5b8 0000000000015e5e 000000003fe839b8 000000003fe83a00
      Call Trace:
      ([<0000000000015d6a>] show_trace+0xe6/0x134)
       [<0000000000039656>] __schedule_bug+0xa2/0xa8
       [<0000000000391744>] schedule+0x49c/0x910
       [<0000000000391f64>] schedule_timeout+0xc4/0x114
       [<00000000003910d4>] wait_for_common+0xe8/0x1b4
       [<00000000000549ae>] call_usermodehelper_exec+0xa6/0xec
       [<00000000001af7b8>] kobject_uevent_env+0x418/0x438
       [<00000000001d08fc>] bus_add_driver+0x1e4/0x298
       [<00000000001d1ee4>] driver_register+0x90/0x18c
       [<0000000000566848>] netiucv_init+0x168/0x2c8
       [<00000000000120be>] do_one_initcall+0x3e/0x17c
       [<000000000054a31a>] kernel_init+0x1ce/0x248
       [<000000000001a97a>] kernel_thread_starter+0x6/0xc
       [<000000000001a974>] kernel_thread_starter+0x0/0xc
       iucv: NETIUCV driver initialized
      initcall netiucv_init+0x0/0x2c8 returned with preemption imbalance
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b122efd
    • Herbert Xu's avatar
      ipsec: Fix pskb_expand_head corruption in xfrm_state_check_space · d01dbeb6
      Herbert Xu authored
      We're never supposed to shrink the headroom or tailroom.  In fact,
      shrinking the headroom is a fatal action.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d01dbeb6
  5. 29 Sep, 2008 18 commits
  6. 28 Sep, 2008 1 commit
  7. 27 Sep, 2008 3 commits