1. 18 9月, 2015 3 次提交
  2. 17 9月, 2015 1 次提交
  3. 16 9月, 2015 5 次提交
  4. 10 9月, 2015 2 次提交
  5. 09 9月, 2015 1 次提交
    • E
      usbnet: Fix a race between usbnet_stop() and the BH · fcb0bb6a
      Eugene Shatokhin 提交于
      The race may happen when a device (e.g. YOTA 4G LTE Modem) is
      unplugged while the system is downloading a large file from the Net.
      
      Hardware breakpoints and Kprobes with delays were used to confirm that
      the race does actually happen.
      
      The race is on skb_queue ('next' pointer) between usbnet_stop()
      and rx_complete(), which, in turn, calls usbnet_bh().
      
      Here is a part of the call stack with the code where the changes to the
      queue happen. The line numbers are for the kernel 4.1.0:
      
      *0 __skb_unlink (skbuff.h:1517)
          prev->next = next;
      *1 defer_bh (usbnet.c:430)
          spin_lock_irqsave(&list->lock, flags);
          old_state = entry->state;
          entry->state = state;
          __skb_unlink(skb, list);
          spin_unlock(&list->lock);
          spin_lock(&dev->done.lock);
          __skb_queue_tail(&dev->done, skb);
          if (dev->done.qlen == 1)
              tasklet_schedule(&dev->bh);
          spin_unlock_irqrestore(&dev->done.lock, flags);
      *2 rx_complete (usbnet.c:640)
          state = defer_bh(dev, skb, &dev->rxq, state);
      
      At the same time, the following code repeatedly checks if the queue is
      empty and reads these values concurrently with the above changes:
      
      *0  usbnet_terminate_urbs (usbnet.c:765)
          /* maybe wait for deletions to finish. */
          while (!skb_queue_empty(&dev->rxq)
              && !skb_queue_empty(&dev->txq)
              && !skb_queue_empty(&dev->done)) {
                  schedule_timeout(msecs_to_jiffies(UNLINK_TIMEOUT_MS));
                  set_current_state(TASK_UNINTERRUPTIBLE);
                  netif_dbg(dev, ifdown, dev->net,
                        "waited for %d urb completions\n", temp);
          }
      *1  usbnet_stop (usbnet.c:806)
          if (!(info->flags & FLAG_AVOID_UNLINK_URBS))
              usbnet_terminate_urbs(dev);
      
      As a result, it is possible, for example, that the skb is removed from
      dev->rxq by __skb_unlink() before the check
      "!skb_queue_empty(&dev->rxq)" in usbnet_terminate_urbs() is made. It is
      also possible in this case that the skb is added to dev->done queue
      after "!skb_queue_empty(&dev->done)" is checked. So
      usbnet_terminate_urbs() may stop waiting and return while dev->done
      queue still has an item.
      
      Locking in defer_bh() and usbnet_terminate_urbs() was revisited to avoid
      this race.
      Signed-off-by: NEugene Shatokhin <eugene.shatokhin@rosalab.ru>
      Reviewed-by: NBjørn Mork <bjorn@mork.no>
      Acked-by: NOliver Neukum <oneukum@suse.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fcb0bb6a
  6. 07 9月, 2015 1 次提交
    • G
      lan78xx: Fix ladv/radv error handling in lan78xx_link_reset() · 99c79ece
      Geert Uytterhoeven 提交于
      net/usb/lan78xx.c: In function ‘lan78xx_link_reset’:
      net/usb/lan78xx.c:1107: warning: comparison is always false due to limited range of data type
      net/usb/lan78xx.c:1111: warning: comparison is always false due to limited range of data type
      
      Assigning return values that can be negative error codes to "u16"
      variables makes them positive, ignoring the errors.  Hence use "int"
      instead.
      
      Drop the "unlikely"s (unlikely considered harmful) and propagate the
      actual error values instead of overriding them to -EIO while we're at
      it.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99c79ece
  7. 01 9月, 2015 1 次提交
  8. 26 8月, 2015 1 次提交
  9. 18 8月, 2015 1 次提交
  10. 13 8月, 2015 2 次提交
  11. 01 8月, 2015 2 次提交
  12. 31 7月, 2015 2 次提交
  13. 27 7月, 2015 3 次提交
  14. 23 7月, 2015 1 次提交
  15. 21 7月, 2015 2 次提交
  16. 12 7月, 2015 1 次提交
  17. 10 7月, 2015 1 次提交
    • E
      cdc_ncm: Add support for moving NDP to end of NCM frame · 4a0e3e98
      Enrico Mioso 提交于
      NCM specs are not actually mandating a specific position in the frame for
      the NDP (Network Datagram Pointer). However, some Huawei devices will
      ignore our aggregates if it is not placed after the datagrams it points
      to. Add support for doing just this, in a per-device configurable way.
      While at it, update NCM subdrivers, disabling this functionality in all of
      them, except in huawei_cdc_ncm where it is enabled instead.
      We aren't making any distinction between different Huawei NCM devices,
      based on what the vendor driver does. Standard NCM devices are left
      unaffected: if they are compliant, they should be always usable, still
      stay on the safe side.
      
      This change has been tested and working with a Huawei E3131 device (which
      works regardless of NDP position), a Huawei E3531 (also working both
      ways) and an E3372 (which mandates NDP to be after indexed datagrams).
      
      V1->V2:
      - corrected wrong NDP acronym definition
      - fixed possible NULL pointer dereference
      - patch cleanup
      V2->V3:
      - Properly account for the NDP size when writing new packets to SKB
      Signed-off-by: NEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0e3e98
  18. 09 7月, 2015 1 次提交
  19. 23 5月, 2015 1 次提交
  20. 10 5月, 2015 2 次提交
  21. 10 4月, 2015 1 次提交
  22. 01 4月, 2015 1 次提交
  23. 30 3月, 2015 2 次提交
  24. 25 3月, 2015 1 次提交
  25. 22 3月, 2015 1 次提交
    • O
      cx82310_eth: wait for firmware to become ready · f40bff42
      Ondrej Zary 提交于
      When the device is powered up, some (older) firmware versions fail to work
      properly if we send commands before the boot is complete (everything is OK
      when the device is hot-plugged). The firmware indicates its ready status by
      putting the link up.
      Newer firmwares delay the first command so they don't suffer from this problem.
      They also report the link being always up.
      
      Wait for firmware to become ready (link up) before sending any commands and/or
      data.
      
      This also allows lowering CMD_TIMEOUT value to a reasonable time.
      
      Tested with 4.1.0.9 (old) and 4.1.0.30 (new) firmware versions.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f40bff42