1. 29 5月, 2018 1 次提交
  2. 04 1月, 2018 2 次提交
    • R
      scsi: doc: fix iscsi-related kernel-doc warnings · ccd4a430
      Randy Dunlap 提交于
      Fix kernel-doc warnings in drivers/scsi/ that are related to iscsi
      support interfaces.
      
      Fixes these kernel-doc warnings: (tested by adding these files to a new
      target.rst documentation file: WIP)
      
      ../drivers/scsi/libiscsi.c:2740: warning: No description found for parameter 'dd_size'
      ../drivers/scsi/libiscsi.c:2740: warning: No description found for parameter 'id'
      ../drivers/scsi/libiscsi.c:2961: warning: No description found for parameter 'cls_conn'
      ../drivers/scsi/iscsi_tcp.c:313: warning: No description found for parameter 'conn'
      ../drivers/scsi/iscsi_tcp.c:363: warning: No description found for parameter 'conn'
      ../drivers/scsi/libiscsi_tcp.c:810: warning: No description found for parameter 'tcp_conn'
      ../drivers/scsi/libiscsi_tcp.c:810: warning: No description found for parameter 'segment'
      ../drivers/scsi/libiscsi_tcp.c:887: warning: No description found for parameter 'offloaded'
      ../drivers/scsi/libiscsi_tcp.c:887: warning: No description found for parameter 'status'
      ../drivers/scsi/libiscsi_tcp.c:887: warning: Excess function parameter 'offload' description in 'iscsi_tcp_recv_skb'
      ../drivers/scsi/libiscsi_tcp.c:964: warning: Excess function parameter 'conn' description in 'iscsi_tcp_task_init'
      ../drivers/scsi/libiscsi_tcp.c:964: warning: Excess function parameter 'sc' description in 'iscsi_tcp_task_init'
      Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
      Cc: "Nicholas A. Bellinger" <nab@linux-iscsi.org>
      Cc: linux-scsi@vger.kernel.org
      Cc: target-devel@vger.kernel.org
      Cc: Sagi Grimberg <sagi@grimberg.me>
      Cc: linux-rdma@vger.kernel.org
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      ccd4a430
    • R
      scsi: libiscsi: Allow sd_shutdown on bad transport · d7549412
      Rafael David Tinoco 提交于
      If, for any reason, userland shuts down iscsi transport interfaces
      before proper logouts - like when logging in to LUNs manually, without
      logging out on server shutdown, or when automated scripts can't
      umount/logout from logged LUNs - kernel will hang forever on its
      sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all
      still existent paths.
      
      PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow"
       #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee
       #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5
       #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199
       #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604
       #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c
       #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10
       #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7
       #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe
       #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7
       #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c
      
      This happens because iscsi_eh_cmd_timed_out(), the transport layer
      timeout helper, would tell the queue timeout function (scsi_times_out)
      to reset the request timer over and over, until the session state is
      back to logged in state. Unfortunately, during server shutdown, this
      might never happen again.
      
      Other option would be "not to handle" the issue in the transport
      layer. That would trigger the error handler logic, which would also need
      the session state to be logged in again.
      
      Best option, for such case, is to tell upper layers that the command was
      handled during the transport layer error handler helper, marking it as
      DID_NO_CONNECT, which will allow completion and inform about the
      problem.
      
      After the session was marked as ISCSI_STATE_FAILED, due to the first
      timeout during the server shutdown phase, all subsequent cmds will fail
      to be queued, allowing upper logic to fail faster.
      Signed-off-by: NRafael David Tinoco <rafael.tinoco@canonical.com>
      Reviewed-by: NLee Duncan <lduncan@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      d7549412
  3. 27 10月, 2017 1 次提交
  4. 12 10月, 2017 1 次提交
  5. 03 10月, 2017 1 次提交
  6. 26 8月, 2017 1 次提交
  7. 13 6月, 2017 1 次提交
    • K
      scsi: libiscsi: use kvzalloc for iscsi_pool_init · bfcc62ed
      Kyle Fortin 提交于
      iscsiadm session login can fail with the following error:
      
      iscsiadm: Could not login to [iface: default, target: iqn.1986-03.com...
      iscsiadm: initiator reported error (9 - internal error)
      
      When /etc/iscsi/iscsid.conf sets node.session.cmds_max = 4096, it
      results in 64K-sized kmallocs per session.  A system under fragmented
      slab pressure may not have any 64K objects available and fail iscsiadm
      session login. Even though memory objects of a smaller size are
      available, the large order allocation ends up failing.
      
      The kernel prints a warning and does dump_stack, like below:
      
      iscsid: page allocation failure: order:4, mode:0xc0d0
      CPU: 0 PID: 2456 Comm: iscsid Not tainted 4.1.12-61.1.28.el6uek.x86_64 #2
      Call Trace:
       [<ffffffff816c6e40>] dump_stack+0x63/0x83
       [<ffffffff8118e58a>] warn_alloc_failed+0xea/0x140
       [<ffffffff81191df9>] __alloc_pages_slowpath+0x409/0x760
       [<ffffffff81192401>] __alloc_pages_nodemask+0x2b1/0x2d0
       [<ffffffffa048f6c0>] ? dev_attr_host_ipaddress+0x20/0xffffffffffffc722
       [<ffffffff811dc38f>] alloc_pages_current+0xaf/0x170
       [<ffffffff81192581>] alloc_kmem_pages+0x31/0xd0
       [<ffffffffa048f600>] ? iscsi_transport_group+0x20/0xffffffffffffc7e2
       [<ffffffff811ad738>] kmalloc_order+0x18/0x50
       [<ffffffff811ad7a4>] kmalloc_order_trace+0x34/0xe0
       [<ffffffff8146ee30>] ? transport_remove_classdev+0x70/0x70
       [<ffffffff811e843d>] __kmalloc+0x27d/0x2a0
       [<ffffffff810c8cbd>] ? complete_all+0x4d/0x60
       [<ffffffffa04af299>] iscsi_pool_init+0x69/0x160 [libiscsi]
       [<ffffffff81465d90>] ? device_initialize+0xb0/0xd0
       [<ffffffffa04af510>] iscsi_session_setup+0x180/0x2f4 [libiscsi]
       [<ffffffffa04c5a60>] ? iscsi_max_lun+0x20/0xfffffffffffffa9e [iscsi_tcp]
       [<ffffffffa04c531f>] iscsi_sw_tcp_session_create+0xcf/0x150 [iscsi_tcp]
       [<ffffffffa04c5a60>] ? iscsi_max_lun+0x20/0xfffffffffffffa9e [iscsi_tcp]
       [<ffffffffa048a633>] iscsi_if_create_session+0x33/0xd0
       [<ffffffffa04c5a60>] ? iscsi_max_lun+0x20/0xfffffffffffffa9e [iscsi_tcp]
       [<ffffffffa048abd8>] iscsi_if_recv_msg+0x508/0x8c0 [scsi_transport_iscsi]
       [<ffffffff811922eb>] ? __alloc_pages_nodemask+0x19b/0x2d0
       [<ffffffff811e6d69>] ? __kmalloc_node_track_caller+0x209/0x2c0
       [<ffffffffa048b00c>] iscsi_if_rx+0x7c/0x200 [scsi_transport_iscsi]
       [<ffffffff81623dc6>] netlink_unicast+0x126/0x1c0
       [<ffffffff8162468c>] netlink_sendmsg+0x36c/0x400
       [<ffffffff815d2fed>] sock_sendmsg+0x4d/0x60
       [<ffffffff815d596a>] ___sys_sendmsg+0x30a/0x330
       [<ffffffff811bc72c>] ? handle_pte_fault+0x20c/0x230
       [<ffffffff811bc90c>] ? __handle_mm_fault+0x1bc/0x330
       [<ffffffff811bcb32>] ? handle_mm_fault+0xb2/0x1a0
       [<ffffffff815d5b99>] __sys_sendmsg+0x49/0x90
       [<ffffffff815d5bf9>] SyS_sendmsg+0x19/0x20
       [<ffffffff816cbb2e>] system_call_fastpath+0x12/0x71
      
      Use kvzalloc for iscsi_pool in iscsi_pool_init.
      Signed-off-by: NKyle Fortin <kyle.fortin@oracle.com>
      Tested-by: NKyle Fortin <kyle.fortin@oracle.com>
      Reviewed-by: NJoseph Slember <joe.slember@oracle.com>
      Reviewed-by: NLance Hartmann <lance.hartmann@oracle.com>
      Acked-by: NLee Duncan <lduncan@suse.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      bfcc62ed
  8. 16 3月, 2017 1 次提交
  9. 02 3月, 2017 1 次提交
  10. 01 3月, 2017 1 次提交
    • C
      scsi: libiscsi: add lock around task lists to fix list corruption regression · 6f8830f5
      Chris Leech 提交于
      There's a rather long standing regression from the commit "libiscsi:
      Reduce locking contention in fast path"
      
      Depending on iSCSI target behavior, it's possible to hit the case in
      iscsi_complete_task where the task is still on a pending list
      (!list_empty(&task->running)).  When that happens the task is removed
      from the list while holding the session back_lock, but other task list
      modification occur under the frwd_lock.  That leads to linked list
      corruption and eventually a panicked system.
      
      Rather than back out the session lock split entirely, in order to try
      and keep some of the performance gains this patch adds another lock to
      maintain the task lists integrity.
      
      Major enterprise supported kernels have been backing out the lock split
      for while now, thanks to the efforts at IBM where a lab setup has the
      most reliable reproducer I've seen on this issue.  This patch has been
      tested there successfully.
      Signed-off-by: NChris Leech <cleech@redhat.com>
      Fixes: 659743b0 ("[SCSI] libiscsi: Reduce locking contention in fast path")
      Reported-by: NPrashantha Subbarao <psubbara@us.ibm.com>
      Reviewed-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Cc: <stable@vger.kernel.org> # v3.15+
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      6f8830f5
  11. 07 2月, 2017 1 次提交
  12. 18 10月, 2016 1 次提交
  13. 12 4月, 2016 2 次提交
  14. 17 9月, 2015 1 次提交
  15. 13 8月, 2015 1 次提交
    • J
      libiscsi: Fix host busy blocking during connection teardown · 660d0831
      John Soni Jose 提交于
      In case of hw iscsi offload, an host can have N-number of active
      connections. There can be IO's running on some connections which
      make host->host_busy always TRUE. Now if logout from a connection
      is tried then the code gets into an infinite loop as host->host_busy
      is always TRUE.
      
       iscsi_conn_teardown(....)
       {
         .........
          /*
           * Block until all in-progress commands for this connection
           * time out or fail.
           */
           for (;;) {
            spin_lock_irqsave(session->host->host_lock, flags);
            if (!atomic_read(&session->host->host_busy)) { /* OK for ERL == 0 */
      	      spin_unlock_irqrestore(session->host->host_lock, flags);
                    break;
            }
           spin_unlock_irqrestore(session->host->host_lock, flags);
           msleep_interruptible(500);
           iscsi_conn_printk(KERN_INFO, conn, "iscsi conn_destroy(): "
                       "host_busy %d host_failed %d\n",
      	          atomic_read(&session->host->host_busy),
      	          session->host->host_failed);
      
      	................
      	...............
           }
        }
      
      This is not an issue with software-iscsi/iser as each cxn is a separate
      host.
      
      Fix:
      Acquiring eh_mutex in iscsi_conn_teardown() before setting
      session->state = ISCSI_STATE_TERMINATE.
      Signed-off-by: NJohn Soni Jose <sony.john@avagotech.com>
      Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
      Reviewed-by: NChris Leech <cleech@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      660d0831
  16. 24 7月, 2015 1 次提交
  17. 24 11月, 2014 2 次提交
  18. 12 11月, 2014 1 次提交
    • C
      scsi: don't set tagging state from scsi_adjust_queue_depth · c8b09f6f
      Christoph Hellwig 提交于
      Remove the tagged argument from scsi_adjust_queue_depth, and just let it
      handle the queue depth.  For most drivers those two are fairly separate,
      given that most modern drivers don't care about the SCSI "tagged" status
      of a command at all, and many old drivers allow queuing of multiple
      untagged commands in the driver.
      
      Instead we start out with the ->simple_tags flag set before calling
      ->slave_configure, which is how all drivers actually looking at
      ->simple_tags except for one worke anyway.  The one other case looks
      broken, but I've kept the behavior as-is for now.
      
      Except for that we only change ->simple_tags from the ->change_queue_type,
      and when rejecting a tag message in a single driver, so keeping this
      churn out of scsi_adjust_queue_depth is a clear win.
      
      Now that the usage of scsi_adjust_queue_depth is more obvious we can
      also remove all the trivial instances in ->slave_alloc or ->slave_configure
      that just set it to the cmd_per_lun default.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMike Christie <michaelc@cs.wisc.edu>
      Reviewed-by: NHannes Reinecke <hare@suse.de>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c8b09f6f
  19. 30 9月, 2014 1 次提交
  20. 19 9月, 2014 1 次提交
  21. 16 9月, 2014 1 次提交
  22. 01 8月, 2014 1 次提交
  23. 25 7月, 2014 1 次提交
  24. 18 7月, 2014 1 次提交
  25. 12 6月, 2014 1 次提交
  26. 19 5月, 2014 1 次提交
  27. 18 3月, 2014 1 次提交
    • S
      SCSI/libiscsi: Add check_protection callback for transports · 55e51eda
      Sagi Grimberg 提交于
      iSCSI needs to be at least aware that a task involves protection
      information.  In case it does, after the transaction completed libiscsi
      will ask the transport to check the protection status of the
      transaction.
      
      Unlike transport errors, DIF errors should not prevent successful
      completion of the transaction from the transport point of view, but
      should be escelated to scsi mid-layer when constructing the scsi
      result and sense data.
      
      check_protection routine will return the ascq corresponding to the DIF
      error that occured (or 0 if no error happened).
      
      return ascq:
      - 0x1: GUARD_CHECK_FAILED
      - 0x2: APPTAG_CHECK_FAILED
      - 0x3: REFTAG_CHECK_FAILED
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NAlex Tabachnik <alext@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      55e51eda
  28. 16 3月, 2014 3 次提交
    • M
      [SCSI] libiscsi: remove unneeded queue work when max_cmdsn is increased · 46a84c65
      Mike Christie 提交于
      iscsi_queuecommand will only take in commands that can fit in the
      current window. So, if a command is on the cmdqueue then it can
      fit in the current window. If a command is on the mgmtqueue, then
      we are setting the immediate bit so they will also fit in the
      window. As a result, we never need to to do a iscsi_conn_queue_work
      when the maxCmdSn is increased.
      
      What should happen is that a command will complete the window will
      be increased, then the scsi layer will send us more commands by
      running the scsi_device queues.
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      46a84c65
    • S
      [SCSI] libiscsi: Reduce locking contention in fast path · 659743b0
      Shlomo Pongratz 提交于
      Replace the session lock with two locks, a forward lock and
      a backwards lock named frwd_lock and back_lock respectively.
      
      The forward lock protects resources that change while sending a
      request to the target, such as cmdsn, queued_cmdsn, and allocating
      task from the commands' pool with kfifo_out.
      
      The backward lock protects resources that change while processing
      a response or in error path, such as cmdsn_exp, cmdsn_max, and
      returning tasks to the commands' pool with kfifo_in.
      
      Under a steady state fast-path situation, that is when one
      or more processes/threads submit IO to an iscsi device and
      a single kernel upcall (e.g softirq) is dealing with processing
      of responses without errors, this patch eliminates the contention
      between the queuecommand()/request response/scsi_done() flows
      associated with iscsi sessions.
      
      Between the forward and the backward locks exists a strict locking
      hierarchy. The mutual exclusion zone protected by the forward lock can
      enclose the mutual exclusion zone protected by the backward lock but not
      vice versa.
      
      For example, in iscsi_conn_teardown or in iscsi_xmit_data when there is
      a failure and __iscsi_put_task is called, the backward lock is taken while
      the forward lock is still taken. On the other hand, if in the RX path a nop
      is to be sent, for example in iscsi_handle_reject or __iscsi_complete_pdu
      than the forward lock is released and the backward lock is taken for the
      duration of iscsi_send_nopout, later the backward lock is released and the
      forward lock is retaken.
      
      libiscsi_tcp uses two kernel fifos the r2t pool and the r2t queue.
      
      The insertion and deletion from these queues didn't corespond to the
      assumption taken by the new forward/backwards session locking paradigm.
      
      That is, in iscsi_tcp_clenup_task which belongs to the RX (backwards)
      path, r2t is taken out from r2t queue and inserted to the r2t pool.
      In iscsi_tcp_get_curr_r2t which belong to the TX (forward) path, r2t
      is also inserted to the r2t pool and another r2t is pulled from r2t
      queue.
      
      Only in iscsi_tcp_r2t_rsp which is called in the RX path but can requeue
      to the TX path, r2t is taken from the r2t pool and inserted to the r2t
      queue.
      
      In order to cope with this situation, two spin locks were added,
      pool2queue and queue2pool. The former protects extracting from the
      r2t pool and inserting to the r2t queue, and the later protects the
      extracing from the r2t queue and inserting to the r2t pool.
      Signed-off-by: NShlomo Pongratz <shlomop@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      [minor fix up to apply cleanly and compile fix]
      Signed-off-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      659743b0
    • V
      [SCSI] iscsi: fix wrong order of opcode and itt in iscsi_handle_reject prompt · e5dbbe27
      Vaughan Cao 提交于
      This patch makes reject messages show right value for opcode and itt, which
      is converse previously.
      Signed-off-by: NVaughan Cao <vaughan.cao@oracle.com>
      Acked-by: NMike Christie <michaelc@cs.wisc.edu>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e5dbbe27
  29. 20 12月, 2013 1 次提交
  30. 26 8月, 2013 1 次提交
  31. 24 8月, 2013 3 次提交
  32. 27 6月, 2013 1 次提交
  33. 12 4月, 2013 1 次提交