1. 31 8月, 2015 3 次提交
  2. 15 7月, 2015 2 次提交
  3. 13 6月, 2015 1 次提交
  4. 28 5月, 2015 1 次提交
    • L
      kernel/params: constify struct kernel_param_ops uses · 9c27847d
      Luis R. Rodriguez 提交于
      Most code already uses consts for the struct kernel_param_ops,
      sweep the kernel for the last offending stragglers. Other than
      include/linux/moduleparam.h and kernel/params.c all other changes
      were generated with the following Coccinelle SmPL patch. Merge
      conflicts between trees can be handled with Coccinelle.
      
      In the future git could get Coccinelle merge support to deal with
      patch --> fail --> grammar --> Coccinelle --> new patch conflicts
      automatically for us on patches where the grammar is available and
      the patch is of high confidence. Consider this a feature request.
      
      Test compiled on x86_64 against:
      
      	* allnoconfig
      	* allmodconfig
      	* allyesconfig
      
      @ const_found @
      identifier ops;
      @@
      
      const struct kernel_param_ops ops = {
      };
      
      @ const_not_found depends on !const_found @
      identifier ops;
      @@
      
      -struct kernel_param_ops ops = {
      +const struct kernel_param_ops ops = {
      };
      
      Generated-by: Coccinelle SmPL
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Junio C Hamano <gitster@pobox.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: cocci@systeme.lip6.fr
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      9c27847d
  5. 19 5月, 2015 10 次提交
  6. 16 4月, 2015 1 次提交
  7. 16 12月, 2014 1 次提交
  8. 04 12月, 2014 1 次提交
  9. 24 11月, 2014 3 次提交
  10. 12 11月, 2014 10 次提交
  11. 14 8月, 2014 1 次提交
  12. 02 8月, 2014 2 次提交
    • B
      IB/srp: Fix residual handling · e714531a
      Bart Van Assche 提交于
      From Documentation/scsi/scsi_mid_low_api.txt: "resid - an LLD should
      set this signed integer to the requested transfer length (i.e.
      'request_bufflen') less the number of bytes that are actually
      transferred."  This means that resid > 0 in case of an underrun and
      also that resid < 0 in case of an overrun.  Modify the SRP initiator
      code such that it matches this requirement.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: NDavid Dillow <dave@thedillows.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      e714531a
    • B
      IB/srp: Fix deadlock between host removal and multipathd · bcc05910
      Bart Van Assche 提交于
      If scsi_remove_host() is invoked after a SCSI device has been blocked,
      if the fast_io_fail_tmo or dev_loss_tmo work gets scheduled on the
      workqueue executing srp_remove_work() and if an I/O request is
      scheduled after the SCSI device had been blocked by e.g. multipathd
      then the following deadlock can occur:
      
          kworker/6:1     D ffff880831f3c460     0   195      2 0x00000000
          Call Trace:
           [<ffffffff814aafd9>] schedule+0x29/0x70
           [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0
           [<ffffffff8105af6f>] msleep+0x2f/0x40
           [<ffffffff8123b0ae>] __blk_drain_queue+0x4e/0x180
           [<ffffffff8123d2d5>] blk_cleanup_queue+0x225/0x230
           [<ffffffffa0010732>] __scsi_remove_device+0x62/0xe0 [scsi_mod]
           [<ffffffffa000ed2f>] scsi_forget_host+0x6f/0x80 [scsi_mod]
           [<ffffffffa0002eba>] scsi_remove_host+0x7a/0x130 [scsi_mod]
           [<ffffffffa07cf5c5>] srp_remove_work+0x95/0x180 [ib_srp]
           [<ffffffff8106d7aa>] process_one_work+0x1ea/0x6c0
           [<ffffffff8106dd9b>] worker_thread+0x11b/0x3a0
           [<ffffffff810758bd>] kthread+0xed/0x110
           [<ffffffff814b972c>] ret_from_fork+0x7c/0xb0
          multipathd      D ffff880096acc460     0  5340      1 0x00000000
          Call Trace:
           [<ffffffff814aafd9>] schedule+0x29/0x70
           [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0
           [<ffffffff814ab79b>] io_schedule_timeout+0x9b/0xf0
           [<ffffffff814abe1c>] wait_for_completion_io_timeout+0xdc/0x110
           [<ffffffff81244b9b>] blk_execute_rq+0x9b/0x100
           [<ffffffff8124f665>] sg_io+0x1a5/0x450
           [<ffffffff8124fd21>] scsi_cmd_ioctl+0x2a1/0x430
           [<ffffffff8124fef2>] scsi_cmd_blk_ioctl+0x42/0x50
           [<ffffffffa00ec97e>] sd_ioctl+0xbe/0x140 [sd_mod]
           [<ffffffff8124bd04>] blkdev_ioctl+0x234/0x840
           [<ffffffff811cb491>] block_ioctl+0x41/0x50
           [<ffffffff811a0df0>] do_vfs_ioctl+0x300/0x520
           [<ffffffff811a1051>] SyS_ioctl+0x41/0x80
           [<ffffffff814b9962>] tracesys+0xd0/0xd5
      
      Fix this by scheduling removal work on another workqueue than the
      transport layer timers.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: NDavid Dillow <dave@thedillows.org>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      bcc05910
  13. 30 5月, 2014 1 次提交
  14. 21 5月, 2014 3 次提交
    • B
      IB/srp: Add fast registration support · 5cfb1782
      Bart Van Assche 提交于
      Certain HCA types (e.g. Connect-IB) and certain configurations (e.g.
      ConnectX VF) support fast registration but not FMR. Hence add fast
      registration support.
      
      In function srp_rport_reconnect(), move the the srp_finish_req()
      loop from after to before the srp_create_target_ib() call. This is
      needed to avoid that srp_finish_req() tries to queue any
      invalidation requests for rkeys associated with the old queue pair
      on the newly allocated queue pair. Invoking srp_finish_req() before
      the queue pair has been reallocated is safe since srp_claim_req()
      handles completions correctly that arrive after srp_finish_req()
      has been invoked.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      5cfb1782
    • B
      IB/srp: Rename FMR-related variables · 52ede08f
      Bart Van Assche 提交于
      The next patch will cause the renamed variables to be shared between
      the code for FMR and for FR memory registration. Make the names of
      these variables independent of the memory registration mode. This
      patch does not change any functionality. The start of this patch was
      the changes applied via the following shell command:
      
      sed -i.orig 's/SRP_FMR_SIZE/SRP_MAX_PAGES_PER_MR/g; \
          s/fmr_page_mask/mr_page_mask/g;s/fmr_page_size/mr_page_size/g; \
          s/fmr_page_shift/mr_page_shift/g;s/fmr_max_size/mr_max_size/g; \
          s/max_pages_per_fmr/max_pages_per_mr/g;s/nfmr/nmdesc/g; \
          s/fmr_len/dma_len/g' drivers/infiniband/ulp/srp/ib_srp.[ch]
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      52ede08f
    • B
      IB/srp: One FMR pool per SRP connection · d1b4289e
      Bart Van Assche 提交于
      Allocate one FMR pool per SRP connection instead of one SRP pool
      per HCA. This improves scalability of the SRP initiator.
      
      Only request the SCSI mid-layer to retry a SCSI command after a
      temporary mapping failure (-ENOMEM) but not after a permanent
      mapping failure. This avoids that SCSI commands are retried
      indefinitely if a permanent memory mapping failure occurs.
      
      Tell the SCSI mid-layer to reduce queue depth temporarily in the
      unlikely case where an application is queuing many requests with
      more than max_pages_per_fmr sg-list elements.
      
      For FMR pool allocation, base the max_pages_per_fmr parameter on
      the HCA memory registration limit. Only try to allocate an FMR
      pool if FMR is supported.
      Signed-off-by: NBart Van Assche <bvanassche@acm.org>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      d1b4289e