Skip to content
  1. Jul 27, 2010
  2. Jul 26, 2010
  3. Jul 25, 2010
    • stephen hemminger's avatar
      net sched: fix race in mirred device removal · 3b87956e
      stephen hemminger authored
      
      
      This fixes hang when target device of mirred packet classifier
      action is removed.
      
      If a mirror or redirection action is configured to cause packets
      to go to another device, the classifier holds a ref count, but was assuming
      the adminstrator cleaned up all redirections before removing. The fix
      is to add a notifier and cleanup during unregister.
      
      The new list is implicitly protected by RTNL mutex because
      it is held during filter add/delete as well as notifier.
      
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Acked-by: default avatarJamal Hadi Salim <hadi@cyberus.ca>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b87956e
    • David S. Miller's avatar
    • Michael S. Tsirkin's avatar
      tun: avoid BUG, dump packet on GSO errors · ef3db4a5
      Michael S. Tsirkin authored
      
      
      There are still some LRO cards that cause GSO errors in tun,
      and BUG on this is an unfriendly way to tell the admin
      to disable LRO.
      
      Further, experience shows we might have more GSO bugs lurking.
      See https://bugzilla.kernel.org/show_bug.cgi?id=16413
      as a recent example.
      dumping a packet will make it easier to figure it out.
      
      Replace BUG with warning+dump+drop the packet to make
      GSO errors in tun less critical and easier to debug.
      
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarAlex Unigovsky <unik@compot.ru>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef3db4a5
    • Greg Edwards's avatar
      bonding: set device in RLB ARP packet handler · d8190dff
      Greg Edwards authored
      After:
      
      commit 6146b1a4
      Author: Jay Vosburgh <fubar@us.ibm.com>
      Date:   Tue Nov 4 17:51:15 2008 -0800
      
          bonding: Fix ALB mode to balance traffic on VLANs
      
      the dev field in the RLB ARP packet handler was set to NULL to wildcard
      and accommodate balancing VLANs on top of bonds.
      
      This has the side-effect of the packet handler being called against
      other, non RLB-enabled bonds, and a kernel oops results when it tries to
      dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
      set for those bonds, e.g. active-backup.
      
      With the __netif_receive_skb() changes from:
      
      commit 1f3c8804
      
      
      Author: Andy Gospodarek <andy@greyhouse.net>
      Date:   Mon Dec 14 10:48:58 2009 +0000
      
          bonding: allow arp_ip_targets on separate vlans to use arp validation
      
      frames received on VLANs correctly make their way to the bond's handler,
      so we no longer need to wildcard the device.
      
      The oops can be reproduced by:
      
      modprobe bonding
      
      echo active-backup > /sys/class/net/bond0/bonding/mode
      echo 100 > /sys/class/net/bond0/bonding/miimon
      ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
      echo +eth0 > /sys/class/net/bond0/bonding/slaves
      echo +eth1 > /sys/class/net/bond0/bonding/slaves
      
      echo +bond1 > /sys/class/net/bonding_masters
      echo balance-alb > /sys/class/net/bond1/bonding/mode
      echo 100 > /sys/class/net/bond1/bonding/miimon
      ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
      echo +eth2 > /sys/class/net/bond1/bonding/slaves
      echo +eth3 > /sys/class/net/bond1/bonding/slaves
      
      Pass some traffic on bond0.  Boom.
      
      [ Tested, behaves as advertised.  I do not believe a test of the bonding
      mode is necessary, as there is no race between the packet handler and
      the bonding mode changing (the mode can only change when the device is
      closed).  Also updated the log message to include the reproduction and
      full commit ids.  -J ]
      
      Signed-off-by: default avatarGreg Edwards <greg.edwards@hp.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Acked-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8190dff
  4. Jul 23, 2010
    • Alexey Shvetsov's avatar
      wimax/i2400m: Add PID & VID for Intel WiMAX 6250 · 41a8730c
      Alexey Shvetsov authored
      
      
      This version of intel wimax device was found in my IBM ThinkPad x201
      
      Signed-off-by: default avatarAlexey Shvetsov <alexxy@gentoo.org>
      41a8730c
    • Brian Haley's avatar
      ipv6: Don't add routes to ipv6 disabled interfaces. · 64e724f6
      Brian Haley authored
      
      
      If the interface has IPv6 disabled, don't add a multicast or
      link-local route since we won't be adding a link-local address.
      
      Reported-by: default avatarMahesh Kelkar <maheshkelkar@gmail.com>
      Signed-off-by: default avatarBrian Haley <brian.haley@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64e724f6
    • David S. Miller's avatar
      net: Fix skb_copy_expand() handling of ->csum_start · be2b6e62
      David S. Miller authored
      
      
      It should only be adjusted if ip_summed == CHECKSUM_PARTIAL.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be2b6e62
    • Andrea Shepard's avatar
      net: Fix corruption of skb csum field in pskb_expand_head() of net/core/skbuff.c · 00c5a983
      Andrea Shepard authored
      
      
      Make pskb_expand_head() check ip_summed to make sure csum_start is really
      csum_start and not csum before adjusting it.
      
      This fixes a bug I encountered using a Sun Quad-Fast Ethernet card and VLANs.
      On my configuration, the sunhme driver produces skbs with differing amounts
      of headroom on receive depending on the packet size.  See line 2030 of
      drivers/net/sunhme.c; packets smaller than RX_COPY_THRESHOLD have 52 bytes
      of headroom but packets larger than that cutoff have only 20 bytes.
      
      When these packets reach the VLAN driver, vlan_check_reorder_header()
      calls skb_cow(), which, if the packet has less than NET_SKB_PAD (== 32) bytes
      of headroom, uses pskb_expand_head() to make more.
      
      Then, pskb_expand_head() needs to adjust a lot of offsets into the skb,
      including csum_start.  Since csum_start is a union with csum, if the packet
      has a valid csum value this will corrupt it, which was the effect I observed.
      The sunhme hardware computes receive checksums, so the skbs would be created
      by the driver with ip_summed == CHECKSUM_COMPLETE and a valid csum field, and
      then pskb_expand_head() would corrupt the csum field, leading to an "hw csum
      error" message later on, for example in icmp_rcv() for pings larger than the
      sunhme RX_COPY_THRESHOLD.
      
      On the basis of the comment at the beginning of include/linux/skbuff.h,
      I believe that the csum_start skb field is only meaningful if ip_csummed is
      CSUM_PARTIAL, so this patch makes pskb_expand_head() adjust it only in that
      case to avoid corrupting a valid csum value.
      
      Please see my more in-depth disucssion of tracking down this bug for
      more details if you like:
      
      http://puellavulnerata.livejournal.com/112186.html
      http://puellavulnerata.livejournal.com/112567.html
      http://puellavulnerata.livejournal.com/112891.html
      http://puellavulnerata.livejournal.com/113096.html
      http://puellavulnerata.livejournal.com/113591.html
      
      I am not subscribed to this list, so please CC me on replies.
      
      Signed-off-by: default avatarAndrea Shepard <andrea@persephoneslair.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      00c5a983
    • Herbert Xu's avatar
      macvtap: Limit packet queue length · 8a35747a
      Herbert Xu authored
      
      
      Mark Wagner reported OOM symptoms when sending UDP traffic over
      a macvtap link to a kvm receiver.
      
      This appears to be caused by the fact that macvtap packet queues
      are unlimited in length.  This means that if the receiver can't
      keep up with the rate of flow, then we will hit OOM. Of course
      it gets worse if the OOM killer then decides to kill the receiver.
      
      This patch imposes a cap on the packet queue length, in the same
      way as the tuntap driver, using the device TX queue length.
      
      Please note that macvtap currently has no way of giving congestion
      notification, that means the software device TX queue cannot be
      used and packets will always be dropped once the macvtap driver
      queue fills up.
      
      This shouldn't be a great problem for the scenario where macvtap
      is used to feed a kvm receiver, as the traffic is most likely
      external in origin so congestion notification can't be applied
      anyway.
      
      Of course, if anybody decides to complain about guest-to-guest
      UDP packet loss down the track, then we may have to revisit this.
      
      Incidentally, this patch also fixes a real memory leak when
      macvtap_get_queue fails.
      
      Chris Wright noticed that for this patch to work, we need a
      non-zero TX queue length.  This patch includes his work to change
      the default macvtap TX queue length to 500.
      
      Reported-by: default avatarMark Wagner <mwagner@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarChris Wright <chrisw@sous-sol.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a35747a
  5. Jul 22, 2010
  6. Jul 21, 2010
  7. Jul 20, 2010
  8. Jul 19, 2010
    • Arnaud Ebalard's avatar
      IPv6: fix CoA check in RH2 input handler (mip6_rthdr_input()) · d9a9dc66
      Arnaud Ebalard authored
      
      
      The input handler for Type 2 Routing Header (mip6_rthdr_input())
      checks if the CoA in the packet matches the CoA in the XFRM state.
      
      Current check is buggy: it compares the adddress in the Type 2
      Routing Header, i.e. the HoA, against the expected CoA in the state.
      The comparison should be made against the address in the destination
      field of the IPv6 header.
      
      The bug remained unnoticed because the main (and possibly only current)
      user of the code (UMIP MIPv6 Daemon) initializes the XFRM state with the
      unspecified address, i.e. explicitly allows everything.
      
      Yoshifuji-san, can you ack that one?
      
      Signed-off-by: default avatarArnaud Ebalard <arno@natisbad.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9a9dc66
  9. Jul 17, 2010
    • Robert Jennings's avatar
      ibmveth: lost IRQ while closing/opening device leads to service loss · ee2e6114
      Robert Jennings authored
      
      
      The order of freeing the IRQ and freeing the device in firmware
      in ibmveth_close can cause the adapter to become unusable after a
      subsequent ibmveth_open.  Only a reboot of the OS will make the
      network device usable again. This is seen when cycling the adapter
      up and down while there is network activity.
      
      There is a window where an IRQ will be left unserviced (H_EOI will not
      be called).  The solution is to make a VIO_IRQ_DISABLE h_call, free the
      device with firmware, and then call free_irq.
      
      Signed-off-by: default avatarRobert Jennings <rcj@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee2e6114
    • David S. Miller's avatar
    • Stephen Boyd's avatar
      rt2x00: Fix lockdep warning in rt2x00lib_probe_dev() · 9acd56d3
      Stephen Boyd authored
      
      
      The rt2x00dev->intf_work workqueue is never initialized when a driver is
      probed for a non-existent device (in this case rt2500usb). On such a
      path we call rt2x00lib_remove_dev() to free any resources initialized
      during the probe before we use INIT_WORK to initialize the workqueue.
      This causes lockdep to get confused since the lock used in the workqueue
      hasn't been initialized yet but is now being acquired during
      cancel_work_sync() called by rt2x00lib_remove_dev().
      
      Fix this by initializing the workqueue first before we attempt to probe
      the device. This should make lockdep happy and avoid breaking any
      assumptions about how the library cleans up after a probe fails.
      
      phy0 -> rt2x00lib_probe_dev: Error - Failed to allocate device.
      INFO: trying to register non-static key.
      the code is fine but needs lockdep annotation.
      turning off the locking correctness validator.
      Pid: 2027, comm: modprobe Not tainted 2.6.35-rc5+ #60
      Call Trace:
       [<ffffffff8105fe59>] register_lock_class+0x152/0x31f
       [<ffffffff81344a00>] ? usb_control_msg+0xd5/0x111
       [<ffffffff81061bde>] __lock_acquire+0xce/0xcf4
       [<ffffffff8105f6fd>] ? trace_hardirqs_off+0xd/0xf
       [<ffffffff81492aef>] ?  _raw_spin_unlock_irqrestore+0x33/0x41
       [<ffffffff810628d5>] lock_acquire+0xd1/0xf7
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f06e>] __cancel_work_timer+0xd0/0x17e
       [<ffffffff8104f037>] ? __cancel_work_timer+0x99/0x17e
       [<ffffffff8104f136>] cancel_work_sync+0xb/0xd
       [<ffffffffa0096675>] rt2x00lib_remove_dev+0x25/0xb0 [rt2x00lib]
       [<ffffffffa0096bf7>] rt2x00lib_probe_dev+0x380/0x3ed [rt2x00lib]
       [<ffffffff811d78a7>] ? __raw_spin_lock_init+0x31/0x52
       [<ffffffffa00bbd2c>] ? T.676+0xe/0x10 [rt2x00usb]
       [<ffffffffa00bbe4f>] rt2x00usb_probe+0x121/0x15e [rt2x00usb]
       [<ffffffff813468bd>] usb_probe_interface+0x151/0x19e
       [<ffffffff812ea08e>] driver_probe_device+0xa7/0x136
       [<ffffffff812ea167>] __driver_attach+0x4a/0x66
       [<ffffffff812ea11d>] ? __driver_attach+0x0/0x66
       [<ffffffff812e96ca>] bus_for_each_dev+0x54/0x89
       [<ffffffff812e9efd>] driver_attach+0x19/0x1b
       [<ffffffff812e9b64>] bus_add_driver+0xb4/0x204
       [<ffffffff812ea41b>] driver_register+0x98/0x109
       [<ffffffff813465dd>] usb_register_driver+0xb2/0x173
       [<ffffffffa00ca000>] ? rt2500usb_init+0x0/0x20 [rt2500usb]
       [<ffffffffa00ca01e>] rt2500usb_init+0x1e/0x20 [rt2500usb]
       [<ffffffff81000203>] do_one_initcall+0x6d/0x17a
       [<ffffffff8106cae8>] sys_init_module+0x9c/0x1e0
       [<ffffffff8100296b>] system_call_fastpath+0x16/0x1b
      
      Signed-off-by: default avatarStephen Boyd <bebarino@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9acd56d3
  10. Jul 16, 2010
  11. Jul 15, 2010
  12. Jul 13, 2010
  13. Jul 12, 2010
  14. Jul 09, 2010