1. 19 Dec, 2013 4 commits
  2. 18 Dec, 2013 13 commits
    • Eric Dumazet's avatar
      ipv6: sit: update mtu check to take care of gso packets · 58a47824
      Eric Dumazet authored
      While testing my changes for TSO support in SIT devices,
      I was using sit0 tunnel which appears to include nopmtudisc flag.
      
      But using :
      
      ip tun add sittun mode sit remote $REMOTE_IPV4 local $LOCAL_IPV4 \
         dev $IFACE
      
      We get a tunnel which rejects too long packets because of the mtu check
      which is not yet GSO aware.
      
      erd:~# ip tunnel
      sittun: ipv6/ip  remote 10.246.17.84  local 10.246.17.83  ttl inherit  6rd-prefix 2002::/16
      sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
      
      This patch is based on an excellent report from
      Michal Shmidt.
      
      In the future, we probably want to extend the MTU check to do the
      right thing for GSO packets...
      
      Fixes: ("61c1db7f ipv6: sit: add GSO/TSO support")
      Reported-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      58a47824
    • Hannes Frederic Sowa's avatar
      ipv6: pmtudisc setting not respected with UFO/CORK · 4df98e76
      Hannes Frederic Sowa authored
      Sockets marked with IPV6_PMTUDISC_PROBE (or later IPV6_PMTUDISC_INTERFACE)
      don't respect this setting when the outgoing interface supports UFO.
      
      We had the same problem in IPv4, which was fixed in commit
      daba287b ("ipv4: fix DO and PROBE pmtu
      mode regarding local fragmentation with UFO/CORK").
      
      Also IPV6_DONTFRAG mode did not care about already corked data, thus
      it may generate a fragmented frame even if this socket option was
      specified. It also did not care about the length of the ipv6 header and
      possible options.
      
      In the error path allow the user to receive the pmtu notifications via
      both, rxpmtu method or error queue. The user may opted in for both,
      so deliver the notification to both error handlers (the handlers check
      if the error needs to be enqueued).
      
      Also report back consistent pmtu values when sending on an already
      cork-appended socket.
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4df98e76
    • Peter Korsgaard's avatar
      dm9601: work around tx fifo sync issue on dm962x · 4263c86d
      Peter Korsgaard authored
      Certain dm962x revisions contain an bug, where if a USB bulk transfer retry
      (E.G. if bulk crc mismatch) happens right after a transfer with odd or
      maxpacket length, the internal tx hardware fifo gets out of sync causing
      the interface to stop working.
      
      Work around it by adding up to 3 bytes of padding to ensure this situation
      cannot trigger.
      
      This workaround also means we never pass multiple-of-maxpacket size skb's
      to usbnet, so the length adjustment to handle usbnet's padding of those can
      be removed.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: default avatarJoseph Chang <joseph_chang@davicom.com.tw>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4263c86d
    • Peter Korsgaard's avatar
      dm9601: make it clear that dm9620/dm9621a are also supported · cabd0e3a
      Peter Korsgaard authored
      The driver nowadays also support dm9620/dm9621a based USB 2.0 ethernet
      adapters, so adjust module/driver description and Kconfig help text to
      match.
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cabd0e3a
    • Peter Korsgaard's avatar
      dm9601: fix reception of full size ethernet frames on dm9620/dm9621a · 407900cf
      Peter Korsgaard authored
      dm9620/dm9621a require room for 4 byte padding even in dm9601 (3 byte
      header) mode.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      407900cf
    • Peter Korsgaard's avatar
      dm9601: add support for dm9621a based dongle · 3b387892
      Peter Korsgaard authored
      dm9621a is functionally identical to dm9620, so the existing handling can
      directly be used.
      
      Thanks to Davicom for sending me a dongle.
      Signed-off-by: default avatarPeter Korsgaard <peter@korsgaard.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3b387892
    • Timo Teräs's avatar
      ip_gre: fix msg_name parsing for recvfrom/recvmsg · 0e3da5bb
      Timo Teräs authored
      ipgre_header_parse() needs to parse the tunnel's ip header and it
      uses mac_header to locate the iphdr. This got broken when gre tunneling
      was refactored as mac_header is no longer updated to point to iphdr.
      Introduce skb_pop_mac_header() helper to do the mac_header assignment
      and use it in ipgre_rcv() to fix msg_name parsing.
      
      Bug introduced in commit c5441932 (GRE: Refactor GRE tunneling code.)
      
      Cc: Pravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e3da5bb
    • Mugunthan V N's avatar
      drivers: net cpsw: Enable In Band mode in cpsw for 10 mbps · a81d8762
      Mugunthan V N authored
      This patch adds support for enabling In Band mode in 10 mbps speed.
      RGMII supports 1 Gig and 100 mbps mode for Forced mode of operation.
      For 10mbps mode it should be configured to in band mode so that link
      status, duplexity and speed are determined from the RGMII input data
      stream
      Signed-off-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a81d8762
    • David S. Miller's avatar
      Merge branch 'bond_locking' · 405a96d6
      David S. Miller authored
      Ding Tianhong says:
      
      ====================
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed and
      bond_3ad_adapter_duplex_changed is called with RTNL only, and
      the functions will modify the port's information with no further
      locking, they will not mutex against bond state machine and
      incoming LACPDU which do not hold RTNL, So I add port lock to
      protect the port information.
      
      But they are not critical bugs, they exist since day one, and till
      now they have never been hit and reported, because change for speed
      and duplex is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup the comments together.
      ====================
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      405a96d6
    • dingtianhong's avatar
      bonding: protect port for bond_3ad_handle_link_change() · 108db736
      dingtianhong authored
      The bond_3ad_handle_link_change is called with RTNL only,
      and the function will modify the port's information with
      no further locking, it will not mutex against bond state
      machine and incoming LACPDU which do not hold RTNL, So I
      add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it and
      add a new pr_debug to debug the port message.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      108db736
    • dingtianhong's avatar
      bonding: protect port for bond_3ad_adapter_duplex_changed() · bca44a73
      dingtianhong authored
      Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it.
      Suggested-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bca44a73
    • dingtianhong's avatar
      bonding: protect port for bond_3ad_adapter_speed_changed() · 71a06c59
      dingtianhong authored
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comment in the function is very old, cleanup it.
      Suggested-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      71a06c59
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 35eecf05
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "Definitely seems quieter this week,
      
        Radeon, intel, intel broadwell, vmwgfx, ttm, armada, and a couple of
        core fixes, one revert in radeon
      
        Most of these are either going to stable or fixes for things
        introduced in the merge window"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (30 commits)
        drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebook
        drm/ttm: Fix accesses through vmas with only partial coverage
        drm/nouveau: only runtime suspend by default in optimus configuration
        drm: don't double-free on driver load error
        Revert "drm/radeon: Implement radeon_pci_shutdown"
        drm/radeon: add missing display tiling setup for oland
        drm/radeon: fix typo in cik_copy_dma
        drm/radeon/cik: plug in missing blit callback
        drm/radeon/dpm: Fix hwmon crash
        drm/radeon: Fix sideport problems on certain RS690 boards
        drm/i915: don't update the dri1 breadcrumb with modesetting
        DRM: Armada: prime refcounting bug fix
        DRM: Armada: fix printing of phys_addr_t/dma_addr_t
        DRM: Armada: destroy framebuffer after helper
        DRM: Armada: implement lastclose() for fbhelper
        drm/i915: Repeat eviction search after idling the GPU
        drm/vmwgfx: Add max surface memory param
        drm/i915: Fix use-after-free in do_switch
        drm/i915: fix pm init ordering
        drm/i915: Hold mutex across i915_gem_release
        ...
      35eecf05
  3. 17 Dec, 2013 23 commits