mchristi | 25 May 09:54 2016

[PATCH 0/5] block/target queue/LUN reset support

Currently, for SCSI LUN_RESETs the target layer can only wait on
bio/requests it has sent. This normally results in the LUN_RESET
timing out on the initiator side and that SCSI error handler
escalating to something more disruptive.

To fix this, the following patches add a block layer helper and
callout to reset a request queue which the target layer can use
to force drivers to complete/fail executing requests.

Patches were made over Jens's block tree's for-next branch.

Bryant G. Ly | 24 May 15:52 2016

[PATCH] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

From: bgly <bgly <at>>

This initial commit contains WIP of the IBM VSCSI Target Fabric
Module. It currently supports read/writes, and I have tested
the ability to create a file backstore with the driver and install
RHEL VIA NIM and then boot up the partition via filio backstore
through the driver.

Signed-off-by: bryantly <bryantly <at>>
 MAINTAINERS                       |   10 +
 drivers/scsi/Kconfig              |   24 +
 drivers/scsi/Makefile             |    2 +
 drivers/scsi/ibmvscsi/Makefile    |    1 +
 drivers/scsi/ibmvscsi/ibmvscsis.c | 2033 +++++++++++++++++++++++++++++++++++++
 drivers/scsi/ibmvscsi/ibmvscsis.h |  160 +++
 drivers/scsi/libsrp.c             |  387 +++++++
 include/scsi/libsrp.h             |   95 ++
 8 files changed, 2712 insertions(+)
 create mode 100644 drivers/scsi/ibmvscsi/ibmvscsis.c
 create mode 100644 drivers/scsi/ibmvscsi/ibmvscsis.h
 create mode 100644 drivers/scsi/libsrp.c
 create mode 100644 include/scsi/libsrp.h

index 6ee06ea..b520e6c 100644
 <at>  <at>  -5381,6 +5381,16  <at>  <at>  S:	Supported
 F:	drivers/scsi/ibmvscsi/ibmvscsi*
(Continue reading)

MRS. LIRA MANDOZA | 22 May 21:11 2016


Attachment (Mrs Lira Mandoza.pdf): application/pdf, 197 KiB
Nicholas A. Bellinger | 17 May 08:08 2016

[PATCH 0/3] Use common iscsi_tpg_np driver show/store

From: Nicholas Bellinger <nab <at>>

Hi Varun & Co,

Here are the outstanding patches for v4.7-rc1 to go
along with initial cxgbit driver merge currently queued
in target-pending/for-next.  Apologies for the delayed
follow-up on these items.

The 1st patch folds existing configfs tpg_np attribute
show/store into common code, as prep for v4.8+ changes
to have each driver's tpg_np attribute provided at runtime,
so existing hardcoded usage in iscsi_target_configfs.c and
enum iscsit_transport_type can be removed.

The remaining 2 patches convert the special cases for
signaling non iser-target rdma verbs shutdown handling
into a iscsit_transport flag, and makes cxgbit usage
of type ISCSI_HW_OFFLOAD + 'hw_offload' attribute use
a driver specific type ISCSI_CXGBIT + 'cxgbit' naming
within configfs.

Note from perspective of new + existing iscsi-target
transport drivers, these patches are purely mechanical

Please review,


(Continue reading)

mchristi | 16 May 20:46 2016

[PATCH 0/2] fix max discard sectors calculation

The following patches were made over Linus's tree. They
fix the max discard sectors calculation in the target
layer and SCSI.

The second patch is a regression fix, so I am ccing stable.

Michael Cyr | 14 May 00:15 2016

[PATCH] Fix for hang of Ordered task in TCM

If a command with a Simple task attribute is failed due to a Unit
Attention, then a subsequent command with an Ordered task attribute will
hang forever.  The reason for this is that the Unit Attention status is
checked for in target_setup_cmd_from_cdb, before the call to
target_execute_cmd, which calls target_handle_task_attr, which in turn
increments dev->simple_cmds.  However, transport_generic_request_failure
still calls transport_complete_task_attr, which will decrement
dev->simple_cmds.  In this case, simple_cmds is now -1.  So when a
command with the Ordered task attribute is sent, target_handle_task_attr
sees that dev->simple_cmds is not 0, so it decides it can't execute the
command until all the (nonexistent) Simple commands have completed.

The solution I've implemented is to move target_scsi3_ua_check, as well as
target_alua_state_check and target_check_reservation, into
target_execute_cmd, after the call to target_handle_task_attr.  I believe
this is actually the correct way this should be handled.  According to
SAM-4 r14, under section 5.14:

"h) if a command other than INQUIRY, REPORT LUNS, REQUEST SENSE, or NOTIFY
DATA TRANSFER DEVICE enters the enabled command state while a unit
attention condition exists for the SCSI initiator port associated with
the I_T nexus on which the command was received, the device server shall
terminate the command with a CHECK CONDITION status. The device server
shall provide sense data that reports a unit attention condition for the
SCSI initiator port that sent the command on the I_T nexus."

But according to section 8.5 and 8.6, a command which is not yet executed
because of the presence of other tasks in the task set (i.e., one for
which target_handle_task_attr returns true) would not enter the enabled
command state; it would be in the dormant command state.
(Continue reading)

Ming Lin | 6 May 08:51 2016

TCMU file handler peformance

Hi Andy,

I'm looking at TCMU's performance.
Just played with tcmu-runner/file_example ...

root <at> target:~# cat /proc/partitions
major minor  #blocks  name

 259        0  937692504 nvme0n1
 259        1    1048576 nvme0n1p1
   8       32    1048576 sdc
   8       48    1048576 sdd

Frontend for both sdc and sdd is loopback
Backend for sdc is iblock
Backend for sdd is tcmu

The underlying device is /dev/nvme0n1p1

Jobs: 4 (f=4): [rrrr] [100.0% done] [967.2MB/0KB/0KB /s] [248K/0/0
iops] [eta 00m:00s]

/dev/sdc(iblock loopback):
Jobs: 4 (f=4): [rrrr] [100.0% done] [965.6MB/0KB/0KB /s] [247K/0/0
iops] [eta 00m:00s]

/dev/sdd(tcmu loopback):
1) First test: drop cache, throughput only about 66M

(Continue reading)

Edoardo | 4 May 10:38 2016

Continuously crashes in kernel 4.5.2

Hi all,
I'm having troubles in my iSCSI target server after the update to
linux-4.5.2. I've always had some trouble, but not this bad.
This time the kernel simply crashes printing out “fixing recursive
fault but reboot is needed”, but reboot is actually the only thing I
can do.
Fortunately I was able to catch the dmesg output thanks to a remote
syslog server.
Can you help me sort this out?
I'm also testing on btrfs filesystem, so some troubles may come from there.

I attached my saved targetcli configuration, and paste the info and
the dmesg output

uname -a :
Linux gentoo-SMB1 4.5.2-gentoo #2 SMP Tue Apr 26 11:36:10 CEST 2016
x86_64 Intel(R) Pentium(R) CPU G3220  <at>  3.00GHz GenuineIntel GNU/Linux

[ 1154.103989] ignoring deprecated emulate_fua_read attribute
[ 1154.104021] ignoring deprecated emulate_dpo attribute
[ 1709.899686] Unable to locate ITT: 0xad891600 on CID: 1, dumping payload
[ 1709.899750] Unable to locate ITT: 0xae891600 on CID: 1, dumping payload
[ 1709.899792] Unable to locate ITT: 0xaf891600 on CID: 1, dumping payload
[ 1709.899841] Unable to locate ITT: 0xb0891600 on CID: 1, dumping payload
[ 1709.899856] Unable to locate ITT: 0xb1891600 on CID: 1, dumping payload
[ 1710.138608] Unable to locate ITT: 0xb2891600 on CID: 1, dumping payload
[ 1714.873446] Unable to locate ITT: 0x5b8a1600 on CID: 1, dumping payload
[ 1714.873513] Unable to locate ITT: 0x5c8a1600 on CID: 1, dumping payload
[ 1714.873644] Unable to locate ITT: 0x5d8a1600 on CID: 1, dumping payload
(Continue reading)

Christoph Hellwig | 3 May 18:01 2016


This series contains patches that implement a first version of a generic
API to handle RDMA READ/WRITE operations as commonly used on the target
(or server) side for storage protocols.

This has been developed for the upcoming NVMe over Fabrics target, and
extensively teѕted as part of that, although this upstream version has
additional updates over the one we're currently using.

It hides details such as the use of MRs for iWarp devices, and will allow
looking at other HCA specifics easily in the future.

This series contains also conversion the SRP and iSER targets to the new

I think it's basically ready to merge now.

I also have a git tree available at:

	git:// rdma-rw-api


Changes since V7:
 - address more review comments from Bart
 - fix a use after free in the SIG MR handling
 - remove the recently added code to try to keep MRs alive when an ioctx
   is on the wait list in the SRP target.

(Continue reading)

Christoph Hellwig | 2 May 15:45 2016

fix and simplify session shutdown V2

Hi Nic,

This series rewrites the session shutdown code so that it is a lot simpler
in the core, doesn't rewrite boilerplat code in the fabrics drivers, and
avoids a race window between session shutdown and unregistration for
Below is receipt from Bart that he used to reproduce the session shutdown

-------- snip --------
* Load the LIO core and ib_srpt kernel modules.
* Configure LIO such that a RAM disk was exported through ib_srpt.
* On the same system, using IB loopback, start srp_daemon such that the
  SRP initiator logs in.
* Add support for LIO LUNs to /etc/multipath.conf with queue_if_no_path
* Start multipath.
* On top of the multipath device that was created for the LIO LUN,
  create a filesystem.
* Run a fio data integrity test on top of that filesystem.
* While fio was running, unload and reload LIO + ib_srpt every 30s.
* Check that the fio IOPS drop to zero while LIO + ib_srpt were being
-------- snip --------

Changes since V1:
 - split out the iSCSI patch to provide a better changelog.  No changes
   to the final code

Paul E. McKenney | 2 May 04:49 2016

Fw: [rcu:rcu/next 41/41] arch/x86/kvm/vmx.c:11022:2: error: function '_r_a_p__v' is initialized like a variable

Like this sort of compiler bug, maybe.  Compiles just fine on my laptop.


							Thanx, Paul

----- Forwarded message from kbuild test robot <fengguang.wu <at>> -----

Date: Mon, 2 May 2016 10:12:38 +0800
From: kbuild test robot <fengguang.wu <at>>
Cc: kbuild-all <at>, "Paul E. McKenney" <paulmck <at>>
Subject: [rcu:rcu/next 41/41] arch/x86/kvm/vmx.c:11022:2: error: function
	'_r_a_p__v' is initialized like a variable

tree: rcu/next
head:   16d7afcaa5301f8243a7dda82be4d59e84ac6ee1
commit: 16d7afcaa5301f8243a7dda82be4d59e84ac6ee1 [41/41] rcu: No ordering for
rcu_assign_pointer() of NULL
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
        git checkout 16d7afcaa5301f8243a7dda82be4d59e84ac6ee1
        # save the attached .config to linux build tree
        make ARCH=x86_64 

Note: the rcu/rcu/next HEAD 16d7afcaa5301f8243a7dda82be4d59e84ac6ee1 builds fine.
      It only hurts bisectibility.

All error/warnings (new ones prefixed by >>):

(Continue reading)