Skip to content

L
linux
Switch branch/tag
  1. 07 Jul, 2017 29 commits
  3. 09 Jun, 2017 10 commits
    • Nicholas Bellinger's avatar
      iscsi-target: Avoid holding ->tpg_state_lock during param update · eceb4459
      Nicholas Bellinger authored 
      As originally reported by Jia-Ju, iscsit_tpg_enable_portal_group()
holds iscsi_portal_group->tpg_state_lock while updating AUTHMETHOD
via iscsi_update_param_value(), which performs a GFP_KERNEL
allocation.

However, since iscsit_tpg_enable_portal_group() is already protected
by iscsit_get_tpg() -> iscsi_portal_group->tpg_access_lock in it's
parent caller, ->tpg_state_lock only needs to be held when setting
TPG_STATE_ACTIVE.
Reported-by: default avatarJia-Ju Bai <baijiaju1990@163.com>
Reviewed-by: default avatarJia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      eceb4459
    • Nicholas Bellinger's avatar
      target/configfs: Kill se_lun->lun_link_magic · 9ae0e9ad
      Nicholas Bellinger authored 
      Instead of using a hardcoded magic value in se_lun when verifying
a target config_item symlink source during target_fabric_mappedlun_link(),
go ahead and use target_fabric_port_item_ops directly instead.
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      9ae0e9ad
    • Nicholas Bellinger's avatar
      target/configfs: Kill se_device->dev_link_magic · c17cd249
      Nicholas Bellinger authored 
      Instead of using a hardcoded magic value in se_device when verifying
a target config_item symlink source during target_fabric_port_link(),
go ahead and use target_core_dev_item_ops directly instead.
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      c17cd249
    • Nicholas Bellinger's avatar
      target/iblock: Convert WRITE_SAME to blkdev_issue_zeroout · 2237498f
      Nicholas Bellinger authored 
      The people who are actively using iblock_execute_write_same_direct() are
doing so in the context of ESX VAAI BlockZero, together with
EXTENDED_COPY and COMPARE_AND_WRITE primitives.

In practice though I've not seen any users of IBLOCK WRITE_SAME for
anything other than VAAI BlockZero, so just using blkdev_issue_zeroout()
when available, and falling back to iblock_execute_write_same() if the
WRITE_SAME buffer contains anything other than zeros should be OK.

(Hook up max_write_zeroes_sectors to signal LBPRZ feature bit in
 target_configure_unmap_from_queue - nab)
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.com>
Cc: Jens Axboe <axboe@fb.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      2237498f
    • Michael Cyr's avatar
      ibmvscsis: Enable Logical Partition Migration Support · 464fd641
      Michael Cyr authored 
      Changes to support a new mechanism from phyp to better synchronize the
logical partition migration (LPM) of the client partition.
This includes a new VIOCTL to register that we support this new
functionality, and 2 new Transport Event types, and finally another
new VIOCTL to let phyp know once we're ready for the Suspend.
Signed-off-by: default avatarMichael Cyr <mikecyr@us.ibm.com>
Signed-off-by: default avatarBryant G. Ly <bryantly@linux.vnet.ibm.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      464fd641
    • Byungchul Park's avatar
      vhost/scsi: Don't reinvent the wheel but use existing llist API · 12bdcbd5
      Byungchul Park authored 
      Although llist provides proper APIs, they are not used. Make them used.
Signed-off-by: default avatarByungchul Park <byungchul.park@lge.com>
Acked-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      12bdcbd5
    • Gustavo A. R. Silva's avatar
      target: remove dead code · fb418240
      Gustavo A. R. Silva authored 
      Local variable _ret_ is assigned to a constant value and it is never
updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 140761
Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
Reviewed-by: default avatarTyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      fb418240
    • Nicholas Bellinger's avatar
      iscsi-target: Reject immediate data underflow larger than SCSI transfer length · abb85a9b
      Nicholas Bellinger authored 
      When iscsi WRITE underflow occurs there are two different scenarios
that can happen.

Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.

That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL.  In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.

However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.

In the wild, we've never had a iscsi host environment actually
try to do this.

For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.

Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:

   commit c72c5250
   Author: Roland Dreier <roland@purestorage.com>
   Date:   Wed Jul 22 15:08:18 2015 -0700

      target: allow underflow/overflow for PR OUT etc. commands

Cc: Roland Dreier <roland@purestorage.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: <stable@vger.kernel.org> # v4.3+
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      abb85a9b
    • Nicholas Bellinger's avatar
      iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP · 105fa2f4
      Nicholas Bellinger authored 
      This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.

This would manifest itself during explicit logout as:

[33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
[33209.078643] ------------[ cut here ]------------
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!

Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn->conn_logout_remove has not been
cleared by the logout type specific post handlers.

To address this special case, if the logout post handler in tx thread
context detects conn->tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.
Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
Tested-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.14+
Tested-by: default avatarGary Guo <ghg@datera.io>
Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      105fa2f4
    • Nicholas Bellinger's avatar
      target: Fix kref->refcount underflow in transport_cmd_finish_abort · 73d4e580
      Nicholas Bellinger authored 
      This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
when a fabric driver drops it's second reference from below the
target_core_tmr.c based callers of transport_cmd_finish_abort().

Recently with the conversion of kref to refcount_t, this bug was
manifesting itself as:

[705519.601034] refcount_t: underflow; use-after-free.
[705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
[705539.719111] ------------[ cut here ]------------
[705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51

Since the original kref atomic_t based kref_put() didn't check for
underflow and only invoked the final callback when zero was reached,
this bug did not manifest in practice since all se_cmd memory is
using preallocated tags.

To address this, go ahead and propigate the existing return from
transport_put_cmd() up via transport_cmd_finish_abort(), and
change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
callers to only do their local target_put_sess_cmd() if necessary.
Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
Tested-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: stable@vger.kernel.org # 3.14+
Tested-by: default avatarGary Guo <ghg@datera.io>
Tested-by: default avatarChu Yuan Lin <cyl@datera.io>
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      73d4e580
  5. 31 May, 2017 1 commit
    • Jiang Yi's avatar
      iscsi-target: Always wait for kthread_should_stop() before kthread exit · 5e0cf5e6
      Jiang Yi authored 
      There are three timing problems in the kthread usages of iscsi_target_mod:

 - np_thread of struct iscsi_np
 - rx_thread and tx_thread of struct iscsi_conn

In iscsit_close_connection(), it calls

 send_sig(SIGINT, conn->tx_thread, 1);
 kthread_stop(conn->tx_thread);

In conn->tx_thread, which is iscsi_target_tx_thread(), when it receive
SIGINT the kthread will exit without checking the return value of
kthread_should_stop().

So if iscsi_target_tx_thread() exit right between send_sig(SIGINT...)
and kthread_stop(...), the kthread_stop() will try to stop an already
stopped kthread.

This is invalid according to the documentation of kthread_stop().

(Fix -ECONNRESET logout handling in iscsi_target_tx_thread and
 early iscsi_target_rx_thread failure case - nab)
Signed-off-by: default avatarJiang Yi <jiangyilism@gmail.com>
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      5e0cf5e6
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7