1. 18 4月, 2017 1 次提交
  2. 15 4月, 2017 1 次提交
    • M
      block: fix bio_will_gap() for first bvec with offset · 5a8d75a1
      Ming Lei 提交于
      Commit 729204ef("block: relax check on sg gap") allows us to merge
      bios, if both are physically contiguous.  This change can merge a huge
      number of small bios, through mkfs for example, mkfs.ntfs running time
      can be decreased to ~1/10.
      
      But if one rq starts with a non-aligned buffer (the 1st bvec's bv_offset
      is non-zero) and if we allow the merge, it is quite difficult to respect
      sg gap limit, especially the max segment size, or we risk having an
      unaligned virtual boundary.  This patch tries to avoid the issue by
      disallowing a merge, if the req starts with an unaligned buffer.
      
      Also add comments to explain why the merged segment can't end in
      unaligned virt boundary.
      
      Fixes: 729204ef ("block: relax check on sg gap")
      Tested-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NMing Lei <ming.lei@redhat.com>
      
      Rewrote parts of the commit message and comments.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      5a8d75a1
  3. 14 4月, 2017 1 次提交
  4. 11 4月, 2017 1 次提交
  5. 08 4月, 2017 3 次提交
  6. 07 4月, 2017 3 次提交
  7. 05 4月, 2017 2 次提交
  8. 04 4月, 2017 4 次提交
  9. 03 4月, 2017 3 次提交
  10. 02 4月, 2017 1 次提交
  11. 01 4月, 2017 4 次提交
  12. 31 3月, 2017 3 次提交
    • M
      target: Fix ALUA transition state race between multiple initiators · d19c4643
      Mike Christie 提交于
      Multiple threads could be writing to alua_access_state at
      the same time, or there could be multiple STPGs in flight
      (different initiators sending them or one initiator sending
      them to different ports), or a combo of both and the
      core_alua_do_transition_tg_pt calls will race with each other.
      
      Because from the last patches we no longer delay running
      core_alua_do_transition_tg_pt_work, there does not seem to be
      any point in running that in a workqueue. And, we always
      wait for it to complete one way or another, so we can sleep
      in this code path. So, this patch made over target-pending just adds a
      mutex and does the work core_alua_do_transition_tg_pt_work was doing in
      core_alua_do_transition_tg_pt.
      
      There is also no need to use an atomic for the
      tg_pt_gp_alua_access_state. In core_alua_do_transition_tg_pt we will
      test and set it under the transition mutex. And, it is a int/32 bits
      so in the other places where it is read, we will never see it partially
      updated.
      Signed-off-by: NMike Christie <mchristi@redhat.com>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      d19c4643
    • N
      target: Fix unknown fabric callback queue-full errors · fa7e25cf
      Nicholas Bellinger 提交于
      This patch fixes a set of queue-full response handling
      bugs, where outgoing responses are leaked when a fabric
      driver is propagating non -EAGAIN or -ENOMEM errors
      to target-core.
      
      It introduces TRANSPORT_COMPLETE_QF_ERR state used to
      signal when CHECK_CONDITION status should be generated,
      when fabric driver ->write_pending(), ->queue_data_in(),
      or ->queue_status() callbacks fail with non -EAGAIN or
      -ENOMEM errors, and data-transfer should not be retried.
      
      Note all fabric driver -EAGAIN and -ENOMEM errors are
      still retried indefinately with associated data-transfer
      callbacks, following existing queue-full logic.
      
      Also fix two missing ->queue_status() queue-full cases
      related to CMD_T_ABORTED w/ TAS status handling.
      Reported-by: NPotnuri Bharat Teja <bharat@chelsio.com>
      Reviewed-by: NPotnuri Bharat Teja <bharat@chelsio.com>
      Tested-by: NPotnuri Bharat Teja <bharat@chelsio.com>
      Cc: Potnuri Bharat Teja <bharat@chelsio.com>
      Reported-by: NSteve Wise <swise@opengridcomputing.com>
      Cc: Steve Wise <swise@opengridcomputing.com>
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      fa7e25cf
    • X
      sctp: alloc stream info when initializing asoc · 3dbcc105
      Xin Long 提交于
      When sending a msg without asoc established, sctp will send INIT packet
      first and then enqueue chunks.
      
      Before receiving INIT_ACK, stream info is not yet alloced. But enqueuing
      chunks needs to access stream info, like out stream state and out stream
      cnt.
      
      This patch is to fix it by allocing out stream info when initializing an
      asoc, allocing in stream and re-allocing out stream when processing init.
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3dbcc105
  13. 30 3月, 2017 2 次提交
    • T
      drm/ttm, drm/vmwgfx: Relax permission checking when opening surfaces · fe25deb7
      Thomas Hellstrom 提交于
      Previously, when a surface was opened using a legacy (non prime) handle,
      it was verified to have been created by a client in the same master realm.
      Relax this so that opening is also allowed recursively if the client
      already has the surface open.
      
      This works around a regression in svga mesa where opening of a shared
      surface is used recursively to obtain surface information.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NSinclair Yeh <syeh@vmware.com>
      fe25deb7
    • N
      target: Avoid mappedlun symlink creation during lun shutdown · 49cb77e2
      Nicholas Bellinger 提交于
      This patch closes a race between se_lun deletion during configfs
      unlink in target_fabric_port_unlink() -> core_dev_del_lun()
      -> core_tpg_remove_lun(), when transport_clear_lun_ref() blocks
      waiting for percpu_ref RCU grace period to finish, but a new
      NodeACL mappedlun is added before the RCU grace period has
      completed.
      
      This can happen in target_fabric_mappedlun_link() because it
      only checks for se_lun->lun_se_dev, which is not cleared until
      after transport_clear_lun_ref() percpu_ref RCU grace period
      finishes.
      
      This bug originally manifested as NULL pointer dereference
      OOPsen in target_stat_scsi_att_intr_port_show_attr_dev() on
      v4.1.y code, because it dereferences lun->lun_se_dev without
      a explicit NULL pointer check.
      
      In post v4.1 code with target-core RCU conversion, the code
      in target_stat_scsi_att_intr_port_show_attr_dev() no longer
      uses se_lun->lun_se_dev, but the same race still exists.
      
      To address the bug, go ahead and set se_lun>lun_shutdown as
      early as possible in core_tpg_remove_lun(), and ensure new
      NodeACL mappedlun creation in target_fabric_mappedlun_link()
      fails during se_lun shutdown.
      Reported-by: NJames Shen <jcs@datera.io>
      Cc: James Shen <jcs@datera.io>
      Tested-by: NJames Shen <jcs@datera.io>
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      49cb77e2
  14. 29 3月, 2017 1 次提交
    • X
      sctp: change to save MSG_MORE flag into assoc · f9ba3501
      Xin Long 提交于
      David Laight noticed the support for MSG_MORE with datamsg->force_delay
      didn't really work as we expected, as the first msg with MSG_MORE set
      would always block the following chunks' dequeuing.
      
      This Patch is to rewrite it by saving the MSG_MORE flag into assoc as
      David Laight suggested.
      
      asoc->force_delay is used to save MSG_MORE flag before a msg is sent.
      All chunks in queue would not be sent out if asoc->force_delay is set
      by the msg with MSG_MORE flag, until a new msg without MSG_MORE flag
      clears asoc->force_delay.
      
      Note that this change would not affect the flush is generated by other
      triggers, like asoc->state != ESTABLISHED, queue size > pmtu etc.
      
      v1->v2:
        Not clear asoc->force_delay after sending the msg with MSG_MORE flag.
      
      Fixes: 4ea0c32f ("sctp: add support for MSG_MORE")
      Signed-off-by: NXin Long <lucien.xin@gmail.com>
      Acked-by: NDavid Laight <david.laight@aculab.com>
      Acked-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f9ba3501
  15. 28 3月, 2017 2 次提交
  16. 25 3月, 2017 3 次提交
  17. 24 3月, 2017 1 次提交
  18. 23 3月, 2017 2 次提交
  19. 22 3月, 2017 2 次提交
    • R
      iommu: Disambiguate MSI region types · 9d3a4de4
      Robin Murphy 提交于
      The introduction of reserved regions has left a couple of rough edges
      which we could do with sorting out sooner rather than later. Since we
      are not yet addressing the potential dynamic aspect of software-managed
      reservations and presenting them at arbitrary fixed addresses, it is
      incongruous that we end up displaying hardware vs. software-managed MSI
      regions to userspace differently, especially since ARM-based systems may
      actually require one or the other, or even potentially both at once,
      (which iommu-dma currently has no hope of dealing with at all). Let's
      resolve the former user-visible inconsistency ASAP before the ABI has
      been baked into a kernel release, in a way that also lays the groundwork
      for the latter shortcoming to be addressed by follow-up patches.
      
      For clarity, rename the software-managed type to IOMMU_RESV_SW_MSI, use
      IOMMU_RESV_MSI to describe the hardware type, and document everything a
      little bit. Since the x86 MSI remapping hardware falls squarely under
      this meaning of IOMMU_RESV_MSI, apply that type to their regions as well,
      so that we tell the same story to userspace across all platforms.
      
      Secondly, as the various region types require quite different handling,
      and it really makes little sense to ever try combining them, convert the
      bitfield-esque #defines to a plain enum in the process before anyone
      gets the wrong impression.
      
      Fixes: d30ddcaa ("iommu: Add a new type field in iommu_resv_region")
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      CC: Alex Williamson <alex.williamson@redhat.com>
      CC: David Woodhouse <dwmw2@infradead.org>
      CC: kvm@vger.kernel.org
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      9d3a4de4
    • P
      hwmon: Add missing HWMON_T_ALARM · a5023a99
      Peter Huewe 提交于
      Unfortunately the HWMON_T_ALARM define was missing,
      although the associated entry was present in hwmon_temp_attributes.
      This is needed to convert drivers to the new interface which use channel
      based alarms.
      Signed-off-by: NPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      a5023a99