1. 30 Mar, 2015 6 commits
  2. 16 Mar, 2015 1 commit
  3. 04 Mar, 2015 2 commits
  4. 03 Mar, 2015 3 commits
    • Alexander Bondar's avatar
      mac80211: Update beacon's timing and DTIM count on every beacon · 2ecc3905
      Alexander Bondar authored
      Beacon's timestamp, device system time associated with this beacon and
      DTIM count parameters are not updated in the associated vif context
      if the latest beacon's content is identical to the previously received.
      It make sense to update these changing parameters on every beacon so the
      driver can get most updated values. This may be necessary, for example,
      to avoid either beacons' drift effect or device time stamp overrun.
      IMPORTANT: Three sync_* parameters - sync_ts, sync_device_ts and
      sync_dtim_count would possibly be out of sync by the time the driver will
      use them. The synchronized view is currently guaranteed only in certain
      Signed-off-by: default avatarAlexander Bondar <alexander.bondar@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Ahmad Kholaif's avatar
      cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events · 6c09e791
      Ahmad Kholaif authored
      This modifies cfg80211_vendor_event_alloc() with an additional argument
      struct wireless_dev *wdev. __cfg80211_alloc_event_skb() is modified to
      take in *wdev argument, if wdev != NULL, both the NL80211_ATTR_IFINDEX
      and wdev identifier are added to the vendor event.
      These changes make it easier for drivers to add ifindex indication in
      vendor events cleanly.
      This also updates all existing users of cfg80211_vendor_event_alloc()
      and __cfg80211_alloc_event_skb() in the kernel tree.
      Signed-off-by: default avatarAhmad Kholaif <akholaif@qca.qualcomm.com>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Dedy Lansky's avatar
      cfg80211: add bss_type and privacy arguments in cfg80211_get_bss() · 6eb18137
      Dedy Lansky authored
      802.11ad adds new a network type (PBSS) and changes the capability
      field interpretation for the DMG (60G) band.
      The same 2 bits that were interpreted as "ESS" and "IBSS" before are
      re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
      values are: "IBSS", "PBSS" (new) and "AP".
      In order to get the BSS struct for the new PBSS networks, change the
      cfg80211_get_bss() function to take a new enum ieee80211_bss_type
      argument with the valid network types, as "capa_mask" and "capa_val"
      no longer work correctly (the search must be band-aware now.)
      The remaining bits in "capa_mask" and "capa_val" are used only for
      privacy matching so replace those two with a privacy enum as well.
      Signed-off-by: default avatarDedy Lansky <dlansky@codeaurora.org>
      [rewrite commit log, tiny fixes]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  5. 28 Feb, 2015 1 commit
  6. 12 Feb, 2015 1 commit
  7. 11 Feb, 2015 3 commits
    • Tom Herbert's avatar
      vxlan: Use checksum partial with remote checksum offload · 0ace2ca8
      Tom Herbert authored
      Change remote checksum handling to set checksum partial as default
      behavior. Added an iflink parameter to configure not using
      checksum partial (calling csum_partial to update checksum).
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Tom Herbert's avatar
      net: Fix remcsum in GRO path to not change packet · 26c4f7da
      Tom Herbert authored
      Remote checksum offload processing is currently the same for both
      the GRO and non-GRO path. When the remote checksum offload option
      is encountered, the checksum field referred to is modified in
      the packet. So in the GRO case, the packet is modified in the
      GRO path and then the operation is skipped when the packet goes
      through the normal path based on skb->remcsum_offload. There is
      a problem in that the packet may be modified in the GRO path, but
      then forwarded off host still containing the remote checksum option.
      A remote host will again perform RCO but now the checksum verification
      will fail since GRO RCO already modified the checksum.
      To fix this, we ensure that GRO restores a packet to it's original
      state before returning. In this model, when GRO processes a remote
      checksum option it still changes the checksum per the algorithm
      but on return from lower layer processing the checksum is restored
      to its original value.
      In this patch we add define gro_remcsum structure which is passed
      to skb_gro_remcsum_process to save offset and delta for the checksum
      being changed. After lower layer processing, skb_gro_remcsum_cleanup
      is called to restore the checksum before returning from GRO.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Paul Moore's avatar
      cipso: don't use IPCB() to locate the CIPSO IP option · 04f81f01
      Paul Moore authored
      Using the IPCB() macro to get the IPv4 options is convenient, but
      unfortunately NetLabel often needs to examine the CIPSO option outside
      of the scope of the IP layer in the stack.  While historically IPCB()
      worked above the IP layer, due to the inclusion of the inet_skb_param
      struct at the head of the {tcp,udp}_skb_cb structs, recent commit
      971f10ec ("tcp: better TCP_SKB_CB layout to reduce cache line misses")
      reordered the tcp_skb_cb struct and invalidated this IPCB() trick.
      This patch fixes the problem by creating a new function,
      cipso_v4_optptr(), which locates the CIPSO option inside the IP header
      without calling IPCB().  Unfortunately, this isn't as fast as a simple
      lookup so some additional tweaks were made to limit the use of this
      new function.
      Cc: <stable@vger.kernel.org> # 3.18
      Reported-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: default avatarPaul Moore <pmoore@redhat.com>
      Tested-by: default avatarCasey Schaufler <casey@schaufler-ca.com>
  8. 09 Feb, 2015 3 commits
  9. 08 Feb, 2015 3 commits
    • Eric Dumazet's avatar
      net: rfs: add hash collision detection · 567e4b79
      Eric Dumazet authored
      Receive Flow Steering is a nice solution but suffers from
      hash collisions when a mix of connected and unconnected traffic
      is received on the host, when flow hash table is populated.
      Also, clearing flow in inet_release() makes RFS not very good
      for short lived flows, as many packets can follow close().
      (FIN , ACK packets, ...)
      This patch extends the information stored into global hash table
      to not only include cpu number, but upper part of the hash value.
      I use a 32bit value, and dynamically split it in two parts.
      For host with less than 64 possible cpus, this gives 6 bits for the
      cpu number, and 26 (32-6) bits for the upper part of the hash.
      Since hash bucket selection use low order bits of the hash, we have
      a full hash match, if /proc/sys/net/core/rps_sock_flow_entries is big
      If the hash found in flow table does not match, we fallback to RPS (if
      it is enabled for the rxqueue).
      This means that a packet for an non connected flow can avoid the
      IPI through a unrelated/victim CPU.
      This also means we no longer have to clear the table at socket
      close time, and this helps short lived flows performance.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Neal Cardwell's avatar
      tcp: mitigate ACK loops for connections as tcp_request_sock · a9b2c06d
      Neal Cardwell authored
      In the SYN_RECV state, where the TCP connection is represented by
      tcp_request_sock, we now rate-limit SYNACKs in response to a client's
      retransmitted SYNs: we do not send a SYNACK in response to client SYN
      if it has been less than sysctl_tcp_invalid_ratelimit (default 500ms)
      since we last sent a SYNACK in response to a client's retransmitted
      This allows the vast majority of legitimate client connections to
      proceed unimpeded, even for the most aggressive platforms, iOS and
      MacOS, which actually retransmit SYNs 1-second intervals for several
      times in a row. They use SYN RTO timeouts following the progression:
      Reported-by: default avatarAvery Fay <avery@mixpanel.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Neal Cardwell's avatar
      tcp: helpers to mitigate ACK loops by rate-limiting out-of-window dupacks · 032ee423
      Neal Cardwell authored
      Helpers for mitigating ACK loops by rate-limiting dupacks sent in
      response to incoming out-of-window packets.
      This patch includes:
      - rate-limiting logic
      - sysctl to control how often we allow dupacks to out-of-window packets
      - SNMP counter for cases where we rate-limited our dupack sending
      The rate-limiting logic in this patch decides to not send dupacks in
      response to out-of-window segments if (a) they are SYNs or pure ACKs
      and (b) the remote endpoint is sending them faster than the configured
      rate limit.
      We rate-limit our responses rather than blocking them entirely or
      resetting the connection, because legitimate connections can rely on
      dupacks in response to some out-of-window segments. For example, zero
      window probes are typically sent with a sequence number that is below
      the current window, and ZWPs thus expect to thus elicit a dupack in
      We allow dupacks in response to TCP segments with data, because these
      may be spurious retransmissions for which the remote endpoint wants to
      receive DSACKs. This is safe because segments with data can't
      realistically be part of ACK loops, which by their nature consist of
      each side sending pure/data-less ACKs to each other.
      The dupack interval is controlled by a new sysctl knob,
      tcp_invalid_ratelimit, given in milliseconds, in case an administrator
      needs to dial this upward in the face of a high-rate DoS attack. The
      name and units are chosen to be analogous to the existing analogous
      knob for ICMP, icmp_ratelimit.
      The default value for tcp_invalid_ratelimit is 500ms, which allows at
      most one such dupack per 500ms. This is chosen to be 2x faster than
      the 1-second minimum RTO interval allowed by RFC 6298 (section 2, rule
      2.4). We allow the extra 2x factor because network delay variations
      can cause packets sent at 1 second intervals to be compressed and
      arrive much closer.
      Reported-by: default avatarAvery Fay <avery@mixpanel.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 05 Feb, 2015 3 commits
    • Erik Kline's avatar
      net: ipv6: allow explicitly choosing optimistic addresses · c58da4c6
      Erik Kline authored
      RFC 4429 ("Optimistic DAD") states that optimistic addresses
      should be treated as deprecated addresses.  From section 2.1:
         Unless noted otherwise, components of the IPv6 protocol stack
         should treat addresses in the Optimistic state equivalently to
         those in the Deprecated state, indicating that the address is
         available for use but should not be used if another suitable
         address is available.
      Optimistic addresses are indeed avoided when other addresses are
      available (i.e. at source address selection time), but they have
      not heretofore been available for things like explicit bind() and
      sendmsg() with struct in6_pktinfo, etc.
      This change makes optimistic addresses treated more like
      deprecated addresses than tentative ones.
      Signed-off-by: default avatarErik Kline <ek@google.com>
      Acked-by: default avatarLorenzo Colitti <lorenzo@google.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      ipv6: fix sparse errors in ip6_make_flowlabel() · 67765146
      Eric Dumazet authored
      include/net/ipv6.h:713:22: warning: incorrect type in assignment (different base types)
      include/net/ipv6.h:713:22:    expected restricted __be32 [usertype] hash
      include/net/ipv6.h:713:22:    got unsigned int
      include/net/ipv6.h:719:25: warning: restricted __be32 degrades to integer
      include/net/ipv6.h:719:22: warning: invalid assignment: ^=
      include/net/ipv6.h:719:22:    left side has type restricted __be32
      include/net/ipv6.h:719:22:    right side has type unsigned int
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Eric Dumazet's avatar
      flow_keys: n_proto type should be __be16 · f4575d35
      Eric Dumazet authored
      (struct flow_keys)->n_proto is in network order, use
      proper type for this.
      Fixes following sparse errors :
      net/core/flow_dissector.c:139:39: warning: incorrect type in assignment (different base types)
      net/core/flow_dissector.c:139:39:    expected unsigned short [unsigned] [usertype] n_proto
      net/core/flow_dissector.c:139:39:    got restricted __be16 [assigned] [usertype] proto
      net/core/flow_dissector.c:237:23: warning: incorrect type in assignment (different base types)
      net/core/flow_dissector.c:237:23:    expected unsigned short [unsigned] [usertype] n_proto
      net/core/flow_dissector.c:237:23:    got restricted __be16 [assigned] [usertype] proto
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: e0f31d84 ("flow_keys: Record IP layer protocol in skb_flow_dissect()")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 04 Feb, 2015 8 commits
  12. 03 Feb, 2015 3 commits
  13. 02 Feb, 2015 3 commits
    • Vlad Yasevich's avatar
      ipv6: introduce ipv6_make_skb · 6422398c
      Vlad Yasevich authored
      This commit is very similar to
      commit 1c32c5ad
      Author: Herbert Xu <herbert@gondor.apana.org.au>
      Date:   Tue Mar 1 02:36:47 2011 +0000
          inet: Add ip_make_skb and ip_finish_skb
      It adds IPv6 version of the helpers ip6_make_skb and ip6_finish_skb.
      The job of ip6_make_skb is to collect messages into an ipv6 packet
      and poplulate ipv6 eader.  The job of ip6_finish_skb is to transmit
      the generated skb.  Together they replicated the job of
      ip6_push_pending_frames() while also provide the capability to be
      called independently.  This will be needed to add lockless UDP sendmsg
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Willem de Bruijn's avatar
      net-timestamp: no-payload only sysctl · b245be1f
      Willem de Bruijn authored
      Tx timestamps are looped onto the error queue on top of an skb. This
      mechanism leaks packet headers to processes unless the no-payload
      options SOF_TIMESTAMPING_OPT_TSONLY is set.
      Add a sysctl that optionally drops looped timestamp with data. This
      only affects processes without CAP_NET_RAW.
      The policy is checked when timestamps are generated in the stack.
      It is possible for timestamps with data to be reported after the
      sysctl is set, if these were queued internally earlier.
      No vulnerability is immediately known that exploits knowledge
      gleaned from packet headers, but it may still be preferable to allow
      administrators to lock down this path at the cost of possible
      breakage of legacy applications.
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
        (v1 -> v2)
        - test socket CAP_NET_RAW instead of capable(CAP_NET_RAW)
        (rfc -> v1)
        - document the sysctl in Documentation/sysctl/net.txt
        - fix access control race: read .._OPT_TSONLY only once,
              use same value for permission check and skb generation.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Christophe Ricard's avatar
      NFC: nci: Add RF NFCEE action notification support · a41bb844
      Christophe Ricard authored
      The NFCC sends an NCI_OP_RF_NFCEE_ACTION_NTF notification
      to the host (DH) to let it know that for example an RF
      transaction with a payment reader is done.
      For now the notification handler is empty.
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>