1. 18 3月, 2015 3 次提交
  2. 07 3月, 2015 1 次提交
  3. 28 2月, 2015 1 次提交
  4. 24 2月, 2015 1 次提交
  5. 20 2月, 2015 2 次提交
    • K
      NVMe: Update SCSI Inquiry VPD 83h translation · 4f1982b4
      Keith Busch 提交于
      The original translation created collisions on Inquiry VPD 83 for many
      existing devices. Newer specifications provide other ways to translate
      based on the device's version can be used to create unique identifiers.
      
      Version 1.1 provides an EUI64 field that uniquely identifies each
      namespace, and 1.2 added the longer NGUID field for the same reason.
      Both follow the IEEE EUI format and readily translate to the SCSI device
      identification EUI designator type 2h. For devices implementing either,
      the translation will use this type, defaulting to the EUI64 8-byte type if
      implemented then NGUID's 16 byte version if not. If neither are provided,
      the 1.0 translation is used, and is updated to use the SCSI String format
      to guarantee a unique identifier.
      
      Knowing when to use the new fields depends on the nvme controller's
      revision. The NVME_VS macro was not decoding this correctly, so that is
      fixed in this patch and moved to a more appropriate place.
      
      Since the Identify Namespace structure required an update for the NGUID
      field, this patch adds the remaining new 1.2 fields to the structure.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      4f1982b4
    • K
      NVMe: Metadata format support · e1e5e564
      Keith Busch 提交于
      Adds support for NVMe metadata formats and exposes block devices for
      all namespaces regardless of their format. Namespace formats that are
      unusable will have disk capacity set to 0, but a handle to the block
      device is created to simplify device management. A namespace is not
      usable when the format requires host interleave block and metadata in
      single buffer, has no provisioned storage, or has better data but failed
      to register with blk integrity.
      
      The namespace has to be scanned in two phases to support separate
      metadata formats. The first establishes the sector size and capacity
      prior to invoking add_disk. If metadata is required, the capacity will
      be temporarilly set to 0 until it can be revalidated and registered with
      the integrity extenstions after add_disk completes.
      
      The driver relies on the integrity extensions to provide the metadata
      buffer. NVMe requires this be a single physically contiguous region,
      so only one integrity segment is allowed per command. If the metadata
      is used for T10 PI, the driver provides mappings to save and restore
      the reftag physical block translation. The driver provides no-op
      functions for generate and verify if metadata is not used for protection
      information. This way the setup is always provided by the block layer.
      
      If a request does not supply a required metadata buffer, the command
      is failed with bad address. This could only happen if a user manually
      disables verify/generate on such a disk. The only exception to where
      this is okay is if the controller is capable of stripping/generating
      the metadata, which is possible on some types of formats.
      
      The metadata scatter gather list now occupies the spot in the nvme_iod
      that used to be used to link retryable IOD's, but we don't do that
      anymore, so the field was unused.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      e1e5e564
  6. 19 2月, 2015 2 次提交
  7. 18 2月, 2015 1 次提交
  8. 17 2月, 2015 2 次提交
  9. 14 2月, 2015 2 次提交
    • T
      drm/i915: Add tiled framebuffer modifiers · 93b81f51
      Tvrtko Ursulin 提交于
      To be used from the new addfb2 extension.
      
      v2:
      - Drop Intel-specific untiled modfier.
      - Move to drm_fourcc.h.
      - Document layouts a bit and denote them as platform-specific and not
        useable for cross-driver sharing.
      - Add Y-tiling for completeness.
      - Drop special docstring markers to avoid confusing kerneldoc.
      
      v3: Give Y-tiling a unique idea, noticed by Tvrtko.
      
      Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1)
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      93b81f51
    • R
      drm: add support for tiled/compressed/etc modifier in addfb2 · e3eb3250
      Rob Clark 提交于
      In DRM/KMS we are lacking a good way to deal with tiled/compressed
      formats.  Especially in the case of dmabuf/prime buffer sharing, where
      we cannot always rely on under-the-hood flags passed to driver specific
      gem-create ioctl to pass around these extra flags.
      
      The proposal is to add a per-plane format modifier.  This allows to, if
      necessary, use different tiling patters for sub-sampled planes, etc.
      The format modifiers are added at the end of the ioctl struct, so for
      legacy userspace it will be zero padded.
      
      v1: original
      v1.5: increase modifier to 64b
      
      v2: Incorporate review comments from the big thread, plus a few more.
      
      - Add a getcap so that userspace doesn't have to jump through hoops.
      - Allow modifiers only when a flag is set. That way drivers know when
        they're dealing with old userspace and need to fish out e.g. tiling
        from other information.
      - After rolling out checks for ->modifier to all drivers I've decided
        that this is way too fragile and needs an explicit opt-in flag. So
        do that instead.
      - Add a define (just for documentation really) for the "NONE"
        modifier. Imo we don't need to add mask #defines since drivers
        really should only do exact matches against values defined with
        fourcc_mod_code.
      - Drop the Samsung tiling modifier on Rob's request since he's not yet
        sure whether that one is accurate.
      
      v3:
      - Also add a new ->modifier[] array to struct drm_framebuffer and fill
        it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin.
      - Remove TODO in comment and add code comment that modifiers should be
        properly documented, requested by Rob.
      
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: Daniel Stone <daniel@fooishbar.org>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Michel Dänzer <michel@daenzer.net>
      Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5)
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Stone <daniels@collabora.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      e3eb3250
  10. 13 2月, 2015 2 次提交
  11. 12 2月, 2015 4 次提交
  12. 11 2月, 2015 4 次提交
  13. 10 2月, 2015 5 次提交
  14. 08 2月, 2015 2 次提交
    • N
      tcp: helpers to mitigate ACK loops by rate-limiting out-of-window dupacks · 032ee423
      Neal Cardwell 提交于
      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
      response.
      
      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: NAvery Fay <avery@mixpanel.com>
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      032ee423
    • J
      net: openvswitch: Support masked set actions. · 83d2b9ba
      Jarno Rajahalme 提交于
      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: NJarno Rajahalme <jrajahalme@nicira.com>
      Acked-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83d2b9ba
  15. 07 2月, 2015 1 次提交
  16. 06 2月, 2015 1 次提交
  17. 05 2月, 2015 2 次提交
    • T
      vfs: add support for a lazytime mount option · 0ae45f63
      Theodore Ts'o 提交于
      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: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      0ae45f63
    • E
      pkt_sched: fq: better control of DDOS traffic · 06eb395f
      Eric Dumazet 提交于
      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: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      06eb395f
  18. 04 2月, 2015 1 次提交
    • D
      drm: remove DRM_FORMAT_NV12MT · 083500ba
      Daniel Vetter 提交于
      So this has been merged originally in
      
      commit 83052d4d
      Author: Seung-Woo Kim <sw0312.kim@samsung.com>
      Date:   Thu Dec 15 15:40:55 2011 +0900
      
          drm: Add multi buffer plane pixel formats
      
      which hasn't seen a lot of review really. The problem is that it's not
      a real pixel format, but just a different way to lay out NV12 pixels
      in macroblocks, i.e. a tiling format.
      
      The new way of doing this is with the soon-to-be-merged fb modifiers.
      
      This was brough up in some long irc discussion around the entire
      topic, as an example of where things have gone wrong. Luckily we can
      correct the mistake:
      - The kms side support for NV12MT is all dead code because
        format_check in drm_crtc.c never accepted NV12MT.
      - The gem side for the gsc support doesn't look better: The code
        forgets to set the pixel format and makes a big mess with the tiling
        mode bits, inadvertedly setting them all.
      
      Conclusion: This never really worked (at least not in upstream) and
      hence we can safely correct our mistake here.
      
      Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
      Cc: Inki Dae <inki.dae@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Rob Clark <robclark@freedesktop.org>
      Cc: Daniel Stone <daniel@fooishbar.org>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NRob Clark <robclark@freedesktop.org>
      Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
      Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
      Acked-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      083500ba
  19. 03 2月, 2015 3 次提交