1. 15 7月, 2015 1 次提交
  2. 13 6月, 2015 1 次提交
  3. 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
  4. 19 5月, 2015 10 次提交
  5. 16 4月, 2015 1 次提交
  6. 16 12月, 2014 1 次提交
  7. 04 12月, 2014 1 次提交
  8. 24 11月, 2014 3 次提交
  9. 12 11月, 2014 10 次提交
  10. 14 8月, 2014 1 次提交
  11. 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
  12. 30 5月, 2014 1 次提交
  13. 21 5月, 2014 7 次提交