1. 14 Nov, 2009 2 commits
    • Vlad Yasevich's avatar
      sctp: Fix regression introduced by new sctp_connectx api · f9c67811
      Vlad Yasevich authored
      A new (unrealeased to the user) sctp_connectx api
      
      c6ba68a2
          sctp: support non-blocking version of the new sctp_connectx() API
      
      introduced a regression cought by the user regression test
      suite.  In particular, the API requires the user library to
      re-allocate the buffer and could potentially trigger a SIGFAULT.
      
      This change corrects that regression by passing the original
      address buffer to the kernel unmodified, but still allows for
      a returned association id.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9c67811
    • Vlad Yasevich's avatar
      sctp: Set source addresses on the association before adding transports · 409b95af
      Vlad Yasevich authored
      Recent commit 8da645e1
      	sctp: Get rid of an extra routing lookup when adding a transport
      introduced a regression in the connection setup.  The behavior was
      
      different between IPv4 and IPv6.  IPv4 case ended up working because the
      route lookup routing returned a NULL route, which triggered another
      route lookup later in the output patch that succeeded.  In the IPv6 case,
      a valid route was returned for first call, but we could not find a valid
      source address at the time since the source addresses were not set on the
      association yet.  Thus resulted in a hung connection.
      
      The solution is to set the source addresses on the association prior to
      adding peers.
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      409b95af
  2. 13 Nov, 2009 1 commit
  3. 10 Nov, 2009 11 commits
  4. 08 Nov, 2009 3 commits
  5. 07 Nov, 2009 14 commits
  6. 06 Nov, 2009 7 commits
    • Sean Cross's avatar
      rt2x00: Don't queue ieee80211 work after USB removal · 66f84d65
      Sean Cross authored
      This prevents the rt2x00 driver from queueing ieee80211 work after the  
      USB card has been removed, preventing a kernel panic.
      Signed-off-by: default avatarSean Cross <sean@chumby.com>
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      66f84d65
    • John W. Linville's avatar
      Revert "ipw2200: fix oops on missing firmware" · 143d40f3
      John W. Linville authored
      This reverts commit e6c5fc53.
      
      Based on this regression report:
      
      Date: Thu, 05 Nov 2009 15:59:16 +0100
      From: Holger Schurig <holgerschurig@gmail.com>
      To: linux-wireless@vger.kernel.org
      Subject: BUG: oops when "rmmod ipw2200"
      
      This happened on wireless-testing v2.6.32-rc6-41575-g5e68bfb. I
      modprobed ipw2200, put it into monitor mode, used tshark a while to
      monitor, then I stopped tshark, "ifconfig eth2 down" and finally
      "rmmod ipw2200", and voila:
      
      [  917.189620] ------------[ cut here ]------------
      [  917.189717] kernel BUG at net/wireless/core.c:543!
      [  917.189805] invalid opcode: 0000 [#1] PREEMPT SMP
      [  917.190002] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:0d.0/firmware/0000:02:0d.0/loading
      [  917.190136] Modules linked in: lib80211_crypt_wep ipw2200(-) libipw lib80211 ath5k mac80211 ath cfg80211 psmouse uhci_hcd
      [  917.190680]
      [  917.190759] Pid: 1763, comm: rmmod Not tainted (2.6.32-rc6-wl #26) Amilo M1425
      [  917.190886] EIP: 0060:[<f8accf34>] EFLAGS: 00010202 CPU: 0
      [  917.190992] EIP is at wiphy_unregister+0xd3/0x175 [cfg80211]
      [  917.191083] EAX: f601d4c4 EBX: 00000000 ECX: 00000000 EDX: f79e8600
      [  917.191176] ESI: f601d400 EDI: f95b4350 EBP: f6009eb4 ESP: f6009e8c
      [  917.191269]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  917.191360] Process rmmod (pid: 1763, ti=f6008000 task=f79e8130 task.ti=f6008000)
      [  917.191486] Stack:
      [  917.191562]  f601d5a0 f601d484 f6460e98 f6009ea0 c01407ee f6009eb8 00000246 f64604c0
      [  917.191916] <0> f6460e5c f95b4350 f6009ec0 f94fd030 f6460e98 f6009edc f95a9d4f f787bc00
      [  917.192100] <0> f787bc58 f787bc00 f95b4350 f95b4350 f6009ee8 c0207fca f787bc58 f6009ef8
      [  917.192100] Call Trace:
      [  917.192100]  [<c01407ee>] ? trace_hardirqs_on+0xb/0xd
      [  917.192100]  [<f94fd030>] ? unregister_ieee80211+0xe/0x27 [libipw]
      [  917.192100]  [<f95a9d4f>] ? ipw_pci_remove+0x59/0x227 [ipw2200]
      [  917.192100]  [<c0207fca>] ? pci_device_remove+0x19/0x39
      [  917.192100]  [<c02b93a4>] ? __device_release_driver+0x59/0x9d
      [  917.192100]  [<c02b944f>] ? driver_detach+0x67/0x85
      [  917.192100]  [<c02b88d6>] ? bus_remove_driver+0x69/0x85
      [  917.192100]  [<c02b9878>] ? driver_unregister+0x4d/0x54
      [  917.192100]  [<c02081c3>] ? pci_unregister_driver+0x28/0x71
      [  917.192100]  [<f95a9cf4>] ? ipw_exit+0x1c/0x1e [ipw2200]
      [  917.192100]  [<c0148e2b>] ? sys_delete_module+0x192/0x1ef
      [  917.192100]  [<c0162cdb>] ? remove_vma+0x52/0x58
      [  917.192100]  [<c01028bb>] ? sysenter_exit+0xf/0x18
      [  917.192100]  [<c0102888>] ? sysenter_do_call+0x12/0x36
      [  917.192100] Code: 74 07 e8 81 bc 8c c7 eb c8 8d 55 e0 89 f8 e8 d6 6d 66 c7 8b 45 dc 31 d2 e8 81 cc 8c c7 8d 86 c4 00 00 00 39 86 c4 00 00 00 74 04 <0f> 0b eb fe 8b 45 dc 8d 5e 0c e8 5a cc 8c c7 8b 86 94 03 00 00
      [  917.192100] EIP: [<f8accf34>] wiphy_unregister+0xd3/0x175 [cfg80211] SS:ESP 0068:f6009e8c
      [  917.203718] ---[ end trace bcaaf449945a5100 ]---
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      143d40f3
    • Eric Dumazet's avatar
      decnet: netdevice refcount leak · 887e671f
      Eric Dumazet authored
      While working on device refcount stuff, I found a device refcount leak
      through DECNET.
      This nasty bug can be used to hold refcounts on any !DECNET netdevice.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      887e671f
    • Jozsef Kadlecsik's avatar
      netfilter: nf_nat: fix NAT issue in 2.6.30.4+ · f9dd09c7
      Jozsef Kadlecsik authored
      Vitezslav Samel discovered that since 2.6.30.4+ active FTP can not work
      over NAT. The "cause" of the problem was a fix of unacknowledged data
      detection with NAT (commit a3a9f79e).
      However, actually, that fix uncovered a long standing bug in TCP conntrack:
      when NAT was enabled, we simply updated the max of the right edge of
      the segments we have seen (td_end), by the offset NAT produced with
      changing IP/port in the data. However, we did not update the other parameter
      (td_maxend) which is affected by the NAT offset. Thus that could drift
      away from the correct value and thus resulted breaking active FTP.
      
      The patch below fixes the issue by *not* updating the conntrack parameters
      from NAT, but instead taking into account the NAT offsets in conntrack in a
      consistent way. (Updating from NAT would be more harder and expensive because
      it'd need to re-calculate parameters we already calculated in conntrack.)
      Signed-off-by: default avatarJozsef Kadlecsik <kadlec@blackhole.kfki.hu>
      Signed-off-by: default avatarPatrick McHardy <kaber@trash.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9dd09c7
    • Sathya Perla's avatar
      f5209b44
    • Eric Dumazet's avatar
      rose: device refcount leak · b4ec8240
      Eric Dumazet authored
      While hunting dev_put() for net-next-2.6, I found a device refcount
      leak in ROSE, ioctl(SIOCADDRT) error path.
      
      Fix is to not touch device refcount, as we hold RTNL
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b4ec8240
    • Stephen Hemminger's avatar
      bridge: prevent bridging wrong device · 1056bd51
      Stephen Hemminger authored
      The bridge code assumes ethernet addressing, so be more strict in
      the what is allowed. This showed up when GRE had a bug and was not
      using correct address format.
      
      Add some more comments for increased clarity.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1056bd51
  7. 05 Nov, 2009 2 commits