1. 02 Sep, 2014 16 commits
  2. 01 Sep, 2014 5 commits
  3. 30 Aug, 2014 9 commits
    • Daniel Borkmann's avatar
      net: sctp: fix ABI mismatch through sctp_assoc_to_state helper · 38ab1fa9
      Daniel Borkmann authored
      Since SCTP day 1, that is, 19b55a2af145 ("Initial commit") from lksctp
      tree, the official <netinet/sctp.h> header carries a copy of enum
      sctp_sstat_state that looks like (compared to the current in-kernel
      enumeration):
      
        User definition:                     Kernel definition:
      
        enum sctp_sstat_state {              typedef enum {
          SCTP_EMPTY             = 0,          <removed>
          SCTP_CLOSED            = 1,          SCTP_STATE_CLOSED            = 0,
          SCTP_COOKIE_WAIT       = 2,          SCTP_STATE_COOKIE_WAIT       = 1,
          SCTP_COOKIE_ECHOED     = 3,          SCTP_STATE_COOKIE_ECHOED     = 2,
          SCTP_ESTABLISHED       = 4,          SCTP_STATE_ESTABLISHED       = 3,
          SCTP_SHUTDOWN_PENDING  = 5,          SCTP_STATE_SHUTDOWN_PENDING  = 4,
          SCTP_SHUTDOWN_SENT     = 6,          SCTP_STATE_SHUTDOWN_SENT     = 5,
          SCTP_SHUTDOWN_RECEIVED = 7,          SCTP_STATE_SHUTDOWN_RECEIVED = 6,
          SCTP_SHUTDOWN_ACK_SENT = 8,          SCTP_STATE_SHUTDOWN_ACK_SENT = 7,
        };                                   } sctp_state_t;
      
      This header was later on also placed into the uapi, so that user space
      programs can compile without having <netinet/sctp.h>, but the shipped
      with <linux/sctp.h> instead.
      
      While RFC6458 under 8.2.1.Association Status (SCTP_STATUS) says that
      sstat_state can range from SCTP_CLOSED to SCTP_SHUTDOWN_ACK_SENT, we
      nevertheless have a what it appears to be dummy SCTP_EMPTY state from
      the very early days.
      
      While it seems to do just nothing, commit 0b8f9e25 ("sctp: remove
      completely unsed EMPTY state") did the right thing and removed this dead
      code. That however, causes an off-by-one when the user asks the SCTP
      stack via SCTP_STATUS API and checks for the current socket state thus
      yielding possibly undefined behaviour in applications as they expect
      the kernel to tell the right thing.
      
      The enumeration had to be changed however as based on the current socket
      state, we access a function pointer lookup-table through this. Therefore,
      I think the best way to deal with this is just to add a helper function
      sctp_assoc_to_state() to encapsulate the off-by-one quirk.
      Reported-by: default avatarTristan Su <sooqing@gmail.com>
      Fixes: 0b8f9e25 ("sctp: remove completely unsed EMPTY state")
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Acked-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      38ab1fa9
    • Eric Dumazet's avatar
      net: attempt a single high order allocation · d9b2938a
      Eric Dumazet authored
      In commit ed98df33 ("net: use __GFP_NORETRY for high order
      allocations") we tried to address one issue caused by order-3
      allocations.
      
      We still observe high latencies and system overhead in situations where
      compaction is not successful.
      
      Instead of trying order-3, order-2, and order-1, do a single order-3
      best effort and immediately fallback to plain order-0.
      
      This mimics slub strategy to fallback to slab min order if the high
      order allocation used for performance failed.
      
      Order-3 allocations give a performance boost only if they can be done
      without recurring and expensive memory scan.
      
      Quoting David :
      
      The page allocator relies on synchronous (sync light) memory compaction
      after direct reclaim for allocations that don't retry and deferred
      compaction doesn't work with this strategy because the allocation order
      is always decreasing from the previous failed attempt.
      
      This means sync light compaction will always be encountered if memory
      cannot be defragmented or reclaimed several times during the
      skb_page_frag_refill() iteration.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9b2938a
    • David S. Miller's avatar
      Merge branch 'mlx4-net' · bcc73547
      David S. Miller authored
      Or Gerlitz says:
      
      ====================
      Setup mlx4 user space Ethernet QPs to properly handle VXLAN
      
      This short series fixes the mlx4 driver setting of user space Ethernet QPs
      (e.g those opened by DPDK applications) such that they will properly handle
      VXLAN traffic/offloads
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcc73547
    • Or Gerlitz's avatar
      mlx4: Set user-space raw Ethernet QPs to properly handle VXLAN traffic · d2fce8a9
      Or Gerlitz authored
      Raw Ethernet QPs opened from user-space lack the proper setup to
      recieve/handle VXLAN traffic when VXLAN offloads are enabled.
      
      Fix that by adding a tunnel steering rule on top of the normal unicast
      steering rule and set the tunnel_type field in the QP context.
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d2fce8a9
    • Or Gerlitz's avatar
      net/mlx4: Move the tunnel steering helper function to mlx4_core · b95089d0
      Or Gerlitz authored
      Move the function which we use to set VXLAN DMFS (flow-steering) rules
      from mlx4_en to mlx4_core. This refactoring will allow the mlx4_ib driver
      to call the helper for the use case of user-space RAW Ethernet QPs, such
      that they can serve VXLAN traffic too.
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b95089d0
    • Giuseppe CAVALLARO's avatar
      stmmac: fix dma api misuse · 362b37be
      Giuseppe CAVALLARO authored
      Enabling DMA_API_DEBUG, warnings are reported at runtime
      because the device driver frees DMA memory with wrong functions
      and it does not call dma_mapping_error after mapping dma memory.
      
      The first problem is fixed by of introducing a flag that helps us
      keeping track which mapping technique was used, so that we can use
      the right API for unmap.
      This approach was inspired by the e1000 driver, which uses a similar
      technique.
      Signed-off-by: default avatarAndre Draszik <andre.draszik@st.com>
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Reviewed-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      362b37be
    • Giuseppe CAVALLARO's avatar
      stmmac: ptp: fix the reference clock · 5566401f
      Giuseppe CAVALLARO authored
      The PTP reference clock, used for setting the addend in the Timestamp Addend
      Register, was erroneously hard-coded (as reported in the databook just as
      example).
      
      The patch removes the macro named: STMMAC_SYSCLOCK and allows to use a
      reference clock (clk_ptp_ref_i) that can be passed from the platform.
      
      If not passed, the main driver clock will be used as default; note that
      this can be fine on some platforms.
      
      Note that, prior this patch, using the old STMMAC_SYSCLOCK on some platforms,
      as side effect, the ptp clock can move faster/slower than the system clock.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5566401f
    • Giuseppe CAVALLARO's avatar
      stmmac: fix tipo on mmc crc error · 2b78d348
      Giuseppe CAVALLARO authored
      This patch is to fix a typo on mmc rx crc error when reported by ethtool.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b78d348
    • Giuseppe CAVALLARO's avatar
      stmmac: prevent false carrier sense detection · b1dee479
      Giuseppe CAVALLARO authored
      This patch is to w/a a problem that happens on some boxes when run at 10Mbps
      Half duplex mode.
      
      During the transmission the CSR signal is asserted for some time and the frames
      aborted because of carrier sense error.
      This is reported by MMC HW counter: txcarrier signal.
      This actually is a false carrier so the frames are good and there is no reason
      to ask for dropping them.
      
      This patch so disables the Carrier Sense During Transmission
      and this means that the MAC transmitter ignore the CRS signal
      during frame transmission in Half-Duplex mode.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Acked-by: default avatarVince Bridgers <vbridgers2013@gmail.com>
      Acked-by: default avatarLey Foon Tan <lftan@altera.com>
      Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1dee479
  4. 27 Aug, 2014 1 commit
  5. 26 Aug, 2014 9 commits
    • David S. Miller's avatar
      mvneta: Add missing if_vlan.h include. · 2d39d120
      David S. Miller authored
      drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_skb_tx_csum':
      drivers/net/ethernet/marvell/mvneta.c:1374:3: error: implicit declaration of function 'vlan_get_protocol' [-Werror=implicit-function-declaration]
         __be16 l3_proto = vlan_get_protocol(skb);
         ^
      Reporeted-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d39d120
    • Wei Liu's avatar
      xen-netback: move netif_napi_add before binding interrupt · e24f8191
      Wei Liu authored
      Interrupt is enabled when bind_interdomain_evtchn_to_irqhandler returns.
      If there's interrupt pending interrupt handler is invoked.
      
      NAPI needs to be initialised before binding interrupt otherwise the
      interrupt handler will try to scheduling a NAPI instance that is not
      initialised yet, resulting in kernel OOPS.
      
      This fixes a regression introduced in ea2c5e13 ("xen-netback: move NAPI
      add/remove calls").
      
      Ideally function calls to create kthreads should also be moved before
      binding but I intent to fix this regression with minimal changes and
      refactor the code with another patch.
      Reported-by: default avatarThomas Leonard <talex5@gmail.com>
      Signed-off-by: default avatarWei Liu <wei.liu2@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e24f8191
    • David S. Miller's avatar
      Merge branch 'tso_fix' · 8dbb200f
      David S. Miller authored
      Vladislav Yasevich says:
      
      ====================
      Fix TSO and checksum issues with non-accelerated vlan traffic.
      
      I've recently ran across something rather interesting when testing vlans
      from inside VMs.  In some scenarios I was getting awfull thruput.
      Some debugging uncovered a very scary packet corruption.  I was
      seeing packets that had original TSO length as IP total length
      and their ip checksum was 0.  This was with e1000e driver.
      
      A bit more debugging uncovered an assumption made by that driver
      that skb->protocol will contain l3 protocol information.  This
      was not the case in my setup since I manually turned off vlan
      tx acceleration for the device.  This caused the driver to not
      initialize the tso information correctly and resulted in
      corrupt TSO frames on the wire.
      
      I decided to do some auditing of the usage of skb->protocols
      in the drivers.  Out of all the drivers, the included 8 appear
      to be effected.  They all allow user to control vlan acceleration
      settings, all support TSO on vlan devices, and all use
      skb->protocol to decide how to encode TSO information.  Some
      also have similar problems when initializing hw checksum information.
      On such device, it is simple enough to reproduce the issue.
      Simply turn off TX VLAN acceleration on the device, create a vlan,
      and run you favorite network performance tool.
      
      There is 1 driver I ran across that I belive will trigger a BUG
      in the system when used with vlans.  That driver is tile/tilepro.c
      I have not changed it in this patch set and would hope that
      the maintainer has time to look at it.
      
      V2: Fix i40ev using the wrong function name.  Full build.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8dbb200f
    • Vlad Yasevich's avatar
      qlge: Fix TSO for non-accelerated vlan traffic · 1ee1cfe7
      Vlad Yasevich authored
      This device claims TSO support for vlans.  It also allows a user to
      control vlan acceleration offloading.  As such, it is possible to turn
      off vlan acceleration and configure a vlan which will continue to send
      TSO traffic.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO information.
      This results in corrupted frames sent on the wire.
      
      This patch extracts the protocol value correctly by using a
      vlan_get_protocol() helper and corrects corrupt TSO frames.
      
      CC: Shahed Shaikh <shahed.shaikh@qlogic.com>
      CC: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
      CC: Ron Mercer <ron.mercer@qlogic.com>
      CC: linux-driver@qlogic.com
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Acked-by: default avatarShahed Shaikh <shahed.shaikh@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ee1cfe7
    • Vlad Yasevich's avatar
      mvneta: Fix TSO and checksum for non-acceleration vlan traffic · 817dbfa5
      Vlad Yasevich authored
      This driver doesn't appear to support vlan acceleration at
      all.  However, it does claim to support TSO and IP checksums
      for vlan devices.  Thus any configured vlan device would
      end up passing down partial checksums or TSO frames.
      
      The driver also uses the value from skb->protocol to
      determine TSO and checksum offload information, but assumes
      that skb->protocol holds the l3 protocol information.
      As a result, vlan traffic with partial checksums or TSO
      will fail those checks and TSO will not happen.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      817dbfa5
    • Vlad Yasevich's avatar
      i40evf: Fix TSO and hw checksums for non-accelerated vlan packets. · a12c4158
      Vlad Yasevich authored
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO and hw checksums.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO and checksum information.
      This results in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a12c4158
    • Vlad Yasevich's avatar
      i40e: Fix TSO and hw checksums for non-accelerated vlan packets. · 3d34dd03
      Vlad Yasevich authored
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO and hw checksums.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO and checksum information.
      This results in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      Fix this by using vlan_get_protocol() helper.
      
      CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: Bruce Allan <bruce.w.allan@intel.com>
      CC: Carolyn Wyborny <carolyn.wyborny@intel.com>
      CC: Don Skidmore <donald.c.skidmore@intel.com>
      CC: Greg Rose <gregory.v.rose@intel.com>
      CC: Alex Duyck <alexander.h.duyck@intel.com>
      CC: John Ronciak <john.ronciak@intel.com>
      CC: Mitch Williams <mitch.a.williams@intel.com>
      CC: Linux NICS <linux.nics@intel.com>
      CC: e1000-devel@lists.sourceforge.net
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d34dd03
    • Vlad Yasevich's avatar
      ehea: Fix TSO and hw checksums with non-accelerated vlan packets. · be1d1486
      Vlad Yasevich authored
      The driver claims that it can do TSO and IP checksums on vlan
      devices and also allows user to control vlan acceleration offloading.
      This makes it possible to push traffic to this driver that has TSO or
      partial checksums set, but also have a non-accelearted vlan
      header.  In this case, the driver will fail to correctly
      identify such traffic and will not correctly perform
      segmentation and checksum calculation.
      
      Fix this by using vlan_get_protocol() helper instead of
      assuming skb->protocol always has this information.
      
      CC: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      be1d1486
    • Vlad Yasevich's avatar
      bna: Support TSO and partial checksum with non-accelerated vlans. · 1c53730a
      Vlad Yasevich authored
      This device claims TSO and checksum support for vlans.  It also
      allows a user to control vlan acceleration offloading.  As such,
      it is possible to turn off vlan acceleration and configure a vlan
      which will continue to support TSO.
      
      In such situation the packet passed down the the device will contain
      a vlan header and skb->protocol will be set to ETH_P_8021Q.
      The device assumes that skb->protocol contains network protocol
      value and uses that value to set up TSO information.  This results
      in corrupted frames sent on the wire.
      
      This patch extract the protocol value correctly and corrects TSO
      and checksums for non-accelerated traffic.
      
      CC: Rasesh Mody <rmody@brocade.com>
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c53730a