1. 06 Mar, 2015 1 commit
    • Ilan peer's avatar
      cfg80211: Add API to change the indoor regulatory setting · 05050753
      Ilan peer authored
      Previously, the indoor setting configuration assumed that as
      long as a station interface is connected, the indoor environment
      setting does not change. However, this assumption is problematic
      - It is possible that a station interface is connected to a mobile
        AP, e.g., softAP or a P2P GO, where it is possible that both the
        station and the mobile AP move out of the indoor environment making
        the indoor setting invalid. In such a case, user space has no way to
        invalidate the setting.
      - A station interface disconnection does not necessarily imply that
        the device is no longer operating in an indoor environment, e.g.,
        it is possible that the station interface is roaming but is still
        stays indoor.
      To handle the above, extend the indoor configuration API to allow
      user space to indicate a change of indoor settings, and allow it to
      indicate weather it controls the indoor setting, such that:
      1. If the user space process explicitly indicates that it is going
         to control the indoor setting, do not clear the indoor setting
         internally, unless the socket is released. The user space process
         should use the NL80211_ATTR_SOCKET_OWNER attribute in the command
         to state that it is going to control the indoor setting.
      2. Reset the indoor setting when restoring the regulatory settings in
         case it is not owned by a user space process.
      Based on the above, a user space tool that continuously monitors the
      indoor settings, i.e., tracking power setting, location etc., can
      indicate environment changes to the regulatory core.
      It should be noted that currently user space is the only provided mechanism
      used to hint to the regulatory core over the indoor/outdoor environment --
      while the country IEs do have an environment setting this has been completely
      ignored by the regulatory core by design for a while now since country IEs
      typically can contain bogus data.
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: default avatarArikX Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarIlan Peer <ilan.peer@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  2. 04 Mar, 2015 1 commit
    • Johannes Berg's avatar
      nl80211: prohibit mixing 'any' and regular wowlan triggers · 98fc4386
      Johannes Berg authored
      If the device supports waking up on 'any' signal - i.e. it continues
      operating as usual and wakes up the host on pretty much anything that
      happens, then it makes no sense to also configure the more restricted
      WoWLAN mode where the device operates more autonomously but also in a
      more restricted fashion.
      Currently only cw2100 supports both 'any' and other triggers, but it
      seems to be broken as it doesn't configure anything to the device, so
      we can't currently get into a situation where both even can correctly
      be configured. This is about to change (Intel devices are going to
      support both and have different behaviour depending on configuration)
      so make sure the conflicting modes cannot be configured.
      (It seems that cw2100 advertises 'any' and 'disconnect' as a means of
      saying that's what it will always do, but that isn't really the way
      this API was meant to be used nor does it actually mean anything as
      'any' always implies 'disconnect' already, and the driver doesn't
      change device configuration in any way depending on the settings.)
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  3. 03 Mar, 2015 2 commits
  4. 28 Feb, 2015 1 commit
    • Masashi Honma's avatar
      nl/mac80211: allow zero plink timeout to disable STA expiration · 31f909a2
      Masashi Honma authored
      Both wpa_supplicant and mac80211 have and inactivity timer. By default
      wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30
      minutes. If wpa_supplicant uses a longer timer than mac80211, it will
      get unexpected disconnection by mac80211.
      Using 0xffffffff instead as the configured value could solve this w/o
      changing the code, but due to integer overflow in the expression used
      this doesn't work. The expression is:
      (current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250)
      On 32bit system, the right side would overflow and be a very small
      value if NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large,
      causing unexpectedly early disconnections.
      Instead allow disabling the inactivity timer to avoid this situation,
      by passing the (previously invalid and useless) value 0.
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      [reword/rewrap commit log]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  5. 17 Feb, 2015 2 commits
  6. 13 Feb, 2015 1 commit
  7. 12 Feb, 2015 1 commit
  8. 11 Feb, 2015 2 commits
  9. 09 Feb, 2015 5 commits
  10. 08 Feb, 2015 2 commits
    • 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>
    • Jarno Rajahalme's avatar
      net: openvswitch: Support masked set actions. · 83d2b9ba
      Jarno Rajahalme authored
      OVS userspace already probes the openvswitch kernel module for
      OVS_ACTION_ATTR_SET_MASKED support.  This patch adds the kernel module
      implementation of masked set actions.
      The existing set action sets many fields at once.  When only a subset
      of the IP header fields, for example, should be modified, all the IP
      fields need to be exact matched so that the other field values can be
      copied to the set action.  A masked set action allows modification of
      an arbitrary subset of the supported header bits without requiring the
      rest to be matched.
      Masked set action is now supported for all writeable key types, except
      for the tunnel key.  The set tunnel action is an exception as any
      input tunnel info is cleared before action processing starts, so there
      is no tunnel info to mask.
      The kernel module converts all (non-tunnel) set actions to masked set
      actions.  This makes action processing more uniform, and results in
      less branching and duplicating the action processing code.  When
      returning actions to userspace, the fully masked set actions are
      converted back to normal set actions.  We use a kernel internal action
      code to be able to tell the userspace provided and converted masked
      set actions apart.
      Signed-off-by: default avatarJarno Rajahalme <jrajahalme@nicira.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 07 Feb, 2015 1 commit
  12. 05 Feb, 2015 2 commits
    • Theodore Ts'o's avatar
      vfs: add support for a lazytime mount option · 0ae45f63
      Theodore Ts'o authored
      Add a new mount option which enables a new "lazytime" mode.  This mode
      causes atime, mtime, and ctime updates to only be made to the
      in-memory version of the inode.  The on-disk times will only get
      updated when (a) if the inode needs to be updated for some non-time
      related change, (b) if userspace calls fsync(), syncfs() or sync(), or
      (c) just before an undeleted inode is evicted from memory.
      This is OK according to POSIX because there are no guarantees after a
      crash unless userspace explicitly requests via a fsync(2) call.
      For workloads which feature a large number of random write to a
      preallocated file, the lazytime mount option significantly reduces
      writes to the inode table.  The repeated 4k writes to a single block
      will result in undesirable stress on flash devices and SMR disk
      drives.  Even on conventional HDD's, the repeated writes to the inode
      table block will trigger Adjacent Track Interference (ATI) remediation
      latencies, which very negatively impact long tail latencies --- which
      is a very big deal for web serving tiers (for example).
      Google-Bug-Id: 18297052
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Eric Dumazet's avatar
      pkt_sched: fq: better control of DDOS traffic · 06eb395f
      Eric Dumazet authored
      FQ has a fast path for skb attached to a socket, as it does not
      have to compute a flow hash. But for other packets, FQ being non
      stochastic means that hosts exposed to random Internet traffic
      can allocate million of flows structure (104 bytes each) pretty
      easily. Not only host can OOM, but lookup in RB trees can take
      too much cpu and memory resources.
      This patch adds a new attribute, orphan_mask, that is adding
      possibility of having a stochastic hash for orphaned skb.
      Its default value is 1024 slots, to mimic SFQ behavior.
      Note: This does not apply to locally generated TCP traffic,
      and no locally generated traffic will share a flow structure
      with another perfect or stochastic flow.
      This patch also handles the specific case of SYNACK messages:
      They are attached to the listener socket, and therefore all map
      to a single hash bucket. If listener have set SO_MAX_PACING_RATE,
      hoping to have new accepted socket inherit this rate, SYNACK
      might be paced and even dropped.
      This is very similar to an internal patch Google have used more
      than one year.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 03 Feb, 2015 1 commit
    • Willem de Bruijn's avatar
      net-timestamp: no-payload option · 49ca0d8b
      Willem de Bruijn authored
      Add timestamping option SOF_TIMESTAMPING_OPT_TSONLY. For transmit
      timestamps, this loops timestamps on top of empty packets.
      Doing so reduces the pressure on SO_RCVBUF. Payload inspection and
      cmsg reception (aside from timestamps) are no longer possible. This
      works together with a follow on patch that allows administrators to
      only allow tx timestamping if it does not loop payload or metadata.
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Changes (rfc -> v1)
        - add documentation
        - remove unnecessary skb->len test (thanks to Richard Cochran)
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  14. 02 Feb, 2015 4 commits
    • Christophe Ricard's avatar
      NFC: Forward NFC_EVT_TRANSACTION to user space · 447b27c4
      Christophe Ricard authored
      NFC_EVT_TRANSACTION is sent through netlink in order for a
      specific application running on a secure element to notify
      userspace of an event. Typically the secure element application
      counterpart on the host could interpret that event and act
      upon it.
      Forwarded information contains:
      - SE host generating the event
      - Application IDentifier doing the operation
      - Applications parameters
      Signed-off-by: default avatarChristophe Ricard <christophe-h.ricard@st.com>
      Signed-off-by: default avatarSamuel Ortiz <sameo@linux.intel.com>
    • Chunyan Zhang's avatar
      tty/serial: Add Spreadtrum sc9836-uart driver support · b7396a38
      Chunyan Zhang authored
      Add a full sc9836-uart driver for SC9836 SoC which is based on the
      spreadtrum sharkl64 platform.
      This driver also support earlycon.
      Originally-by: default avatarLanqing Liu <lanqing.liu@spreadtrum.com>
      Signed-off-by: default avatarOrson Zhai <orson.zhai@spreadtrum.com>
      Signed-off-by: default avatarChunyan Zhang <chunyan.zhang@spreadtrum.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Christoph Hellwig's avatar
      nfsd: implement pNFS operations · 9cf514cc
      Christoph Hellwig authored
      LAYOUTRETURN NFSv4.1 operations, as well as backing code to manage
      outstanding layouts and devices.
      Layout management is very straight forward, with a nfs4_layout_stateid
      structure that extends nfs4_stid to manage layout stateids as the
      top-level structure.  It is linked into the nfs4_file and nfs4_client
      structures like the other stateids, and contains a linked list of
      layouts that hang of the stateid.  The actual layout operations are
      implemented in layout drivers that are not part of this commit, but
      will be added later.
      The worst part of this commit is the management of the pNFS device IDs,
      which suffers from a specification that is not sanely implementable due
      to the fact that the device-IDs are global and not bound to an export,
      and have a small enough size so that we can't store the fsid portion of
      a file handle, and must never be reused.  As we still do need perform all
      export authentication and validation checks on a device ID passed to
      GETDEVICEINFO we are caught between a rock and a hard place.  To work
      around this issue we add a new hash that maps from a 64-bit integer to a
      fsid so that we can look up the export to authenticate against it,
      a 32-bit integer as a generation that we can bump when changing the device,
      and a currently unused 32-bit integer that could be used in the future
      to handle more than a single device per export.  Entries in this hash
      table are never deleted as we can't reuse the ids anyway, and would have
      a severe lifetime problem anyway as Linux export structures are temporary
      structures that can go away under load.
      Parts of the XDR data, structures and marshaling/unmarshaling code, as
      well as many concepts are derived from the old pNFS server implementation
      from Andy Adamson, Benny Halevy, Dean Hildebrand, Marc Eshel, Fred Isaman,
      Mike Sager, Ricardo Labiaga and many others.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
    • Lars-Peter Clausen's avatar
      [media] adv7180: Add fast switch support · 08b717c2
      Lars-Peter Clausen authored
      In fast switch mode the adv7180 (and similar) can lock onto a new signal
      faster when switching between different inputs. As a downside though it is
      no longer able to auto-detect the incoming format.
      The fast switch mode is exposed as a boolean v4l control that allows
      userspace applications to either enable or disable fast switch mode.
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Acked-by: default avatarFederico Vaga <federico.vaga@gmail.com>
      Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
  15. 31 Jan, 2015 1 commit
  16. 29 Jan, 2015 2 commits
  17. 28 Jan, 2015 1 commit
  18. 27 Jan, 2015 2 commits
  19. 26 Jan, 2015 1 commit
    • Joe Stringer's avatar
      openvswitch: Add support for unique flow IDs. · 74ed7ab9
      Joe Stringer authored
      Previously, flows were manipulated by userspace specifying a full,
      unmasked flow key. This adds significant burden onto flow
      serialization/deserialization, particularly when dumping flows.
      This patch adds an alternative way to refer to flows using a
      variable-length "unique flow identifier" (UFID). At flow setup time,
      userspace may specify a UFID for a flow, which is stored with the flow
      and inserted into a separate table for lookup, in addition to the
      standard flow table. Flows created using a UFID must be fetched or
      deleted using the UFID.
      All flow dump operations may now be made more terse with OVS_UFID_F_*
      flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
      omit the flow key from a datapath operation if the flow has a
      corresponding UFID. This significantly reduces the time spent assembling
      and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
      enabled, the datapath only returns the UFID and statistics for each flow
      during flow dump, increasing ovs-vswitchd revalidator performance by 40%
      or more.
      Signed-off-by: default avatarJoe Stringer <joestringer@nicira.com>
      Acked-by: default avatarPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  20. 25 Jan, 2015 1 commit
  21. 24 Jan, 2015 1 commit
  22. 23 Jan, 2015 4 commits
  23. 21 Jan, 2015 1 commit