Sumit Rai | 23 Jun 13:49 2016

OOPS Trying to add second TCP connection to iSCSI session

We are testing "Adding a second connection to existing iSCSI session” with below steps:

Step 1. Initiator successfully performs iSCSI login on a tcp connection (b/w initiator and target) to
establish iSCSI session. 
Step 2. Establish a second TCP connection to the target.
Step 3. Start login on the second TCP connection using ISID and TSIH of iSCSI session established in Step 1.

During Step 3, OOPS is observed on target side. All further attempts to connect to iSCSI target fails after
the OOPS. 

LIO Version: Datera Inc. iSCSI Target v4.1.0
Linux Kernel: 4.4.0-22-generic

dmesg
=====
[  862.784477] BUG: unable to handle kernel NULL pointer dereference at 00000000000001f8
[  862.784486] IP: [<ffffffffc0604b44>] iscsi_target_login_thread+0x724/0xfa0 [iscsi_target_mod]
[  862.784570] PGD 0 
[  862.784572] Oops: 0000 [#1] SMP 
[  862.784575] Modules linked in: target_core_user uio tcm_fc libfc ib_srpt tcm_usb_gadget
libcomposite udc_core tcm_loop vhost_scsi vhost iscsi_target_mod tcm_qla2xxx qla2xxx
scsi_transport_fc target_core_file target_core_iblock target_core_pscsi target_core_mod
configfs pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE)
vmw_vsock_vmci_transport vsock vmhgfs(OE) coretemp kvm_intel kvm binfmt_misc irqbypass
crct10dif_pclmul crc32_pclmul aesni_intel vmw_balloon aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd joydev input_leds serio_raw i2c_piix4 vmw_vmci shpchp 8250_fintek mac_hid
ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi
scsi_transport_iscsi parport_pc ppdev lp parport autofs4 hid_generic usbhid hid vmwgfx ttm psmouse
drm_kms_helper syscopyarea
[  862.784609]  sysfillrect sysimgblt mptspi mptscsih fb_sys_fops drm ahci libahci e1000 mptbase
(Continue reading)

Andy Grover | 22 Jun 19:04 2016
Picon
Gravatar

Notice: Moved some github repos to 'open-iscsi' org

Hi all,

I have moved some LIO-related github repos from my personal github 
account (agrover) to the open-iscsi organization. This includes:

targetcli-fb
configshell-fb
rtslib-fb
targetd
tcmu-runner

No changes should be needed for existing cloned or forked repos.

Regards -- Andy
Sumit Rai | 22 Jun 16:13 2016

LIO seems to use SCSI Allocation Length instead of SPDTL for calculating ResidualCount

We are trying to test if LIO target sets ResidualCount correctly in case of ResidualOverflow for Data-In by
following the below Steps:
1. Send SCSI Inquiry command to iSCSI target, if there are no exceptions in the response (and no residual
overflow) we are able to determine how many bytes the target SCSI layer on target side attempted to
transfer to target iSCSI layer. On the initiator side when response is received: in the absence of any
exceptions or residual overflow we assume all the data was successfully transferred and is equal to iSCSI
DataSegmentLength. We will use this value as SPDTL for SCSI Inquiry command.

Note: SPDTL is detailed in RFC 7143 11.4.5.2 (and you may also refer to discussion on T10 mailing list: http://www.t10.org/pipermail/t10/2014-June/017367.html).

2. Send out the same SCSI inquiry command as in Step 1. but set iSCSI EDTL to a value lower than SPDTL.

Assumption: Since we are not making any changes to iSCSI target LU configuration in our setup b/w Step 1. and
2, we assume amount of Inquiry Data target generates will be same of 1. and 2. since inquiry command is the
same. During our testing we find this assumption to be true.

Expected Result:
Since in Step 2, SPDTL > EDTL, iSCSI target is expected to set ResidualOverflow flag and ResidualCount to
SPDTL - EDTL.
In the attached PCAP text file, frame no. 11 (SCSI Inquiry Req.) and 12 (Inquiry Response) are for Step 1. As
explained, SPDTL = 0x24 or 36D.
Frame no. 14 is for (SCSI Inq. Req.) Step 2. EDTL = 0x08.
Hence, expected ResidualCount = 0x1C (28D) i.e. 0x24 (36D) - 0x08 (8D)

Observed Result:
iSCSI target sets the Residual Overflow flag correctly but value of ResidualCount doesn’t match
expected value.
Target is setting, ResidualCount to 0x3f8 (1016D) as seen in frame no 16. In the frame no. 14, in the SCSI
Inquiry CDB allocation length (SPC 5r01 Section 4.2.5.6) was set to 0x0400 (1024D) and target seems to be
using this value to calculate ResidualCount i.e. 0x0400 (1024D) - 0x08.
(Continue reading)

Arnd Bergmann | 22 Jun 14:55 2016
Picon
Gravatar

[PATCH] target/iblock: use ilog2 to compute block size

Enabling CONFIG_UBSAN_SANITIZE_ALL on ARM caused a link error:

drivers/target/built-in.o: In function `iblock_emulate_read_cap_with_block_size.constprop.1':
target_core_iblock.c:(.text+0xc2774): undefined reference to `____ilog2_NaN'
target_core_iblock.c:(.text+0xc27f8): undefined reference to `__aeabi_uldivmod'
target_core_iblock.c:(.text+0xc299c): undefined reference to `__aeabi_uldivmod'

This is caused by gcc not behaving in the expected ways with __builtin_constant_p(),
but it also points to somewhat inefficient code: As we know that the
block size is a power-of-two value, we can turn the expensive 64-bit
division into a simpler variable bit shift.

Signed-off-by: Arnd Bergmann <arnd <at> arndb.de>
---
 drivers/target/target_core_iblock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index 22af12f8b8eb..3ab4e2d1202c 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
 <at>  <at>  -201,9 +201,9  <at>  <at>  static unsigned long long iblock_emulate_read_cap_with_block_size(
 	struct block_device *bd,
 	struct request_queue *q)
 {
-	unsigned long long blocks_long = (div_u64(i_size_read(bd->bd_inode),
-					bdev_logical_block_size(bd)) - 1);
 	u32 block_size = bdev_logical_block_size(bd);
+	unsigned int block_shift = ilog2(block_size);
+	unsigned long long blocks_long = (i_size_read(bd->bd_inode) >> block_shift) - 1;
(Continue reading)

Chris Friesen | 15 Jun 20:27 2016

[bug?] "vgs" command hanging after running "targetctl clear"

I'm running a CentOS-7 based system, so if that disqualifies me due to the 
amount of kernel patches please let me know. :)

Anyways, I've run into some weird behaviour.  I have a single system.  I'm 
exporting an ISCSI target using targetctl.  The backing store is a 
thinly-provisioned LVM volume, where the underlying PV is a single drbd device, 
which in turn is backed by /dev/sdb1.  The LVM/drbd setup (as well as other 
configuration) is done by scripts and I'm not aware of all the exact config details.

I'm using iscsiadm to discover and then login to the target, so that "ls -l 
/dev/disk/by-path" shows this:

lrwxrwxrwx 1 root root  9 Jun 15 16:36 
ip-127.0.0.1:3260-iscsi-iqn.2014-10.com.example.server1:iscsi-1-lun-0 -> ../../sdc

Now here's where it gets a bit odd.  If I run "targetctl clear", then run "vgs", 
the vgs command hangs.  /proc/≤pid>/stack for the hung process looks like this:

controller-0:/home/wrsroot# cat /proc/15379/stack
[<ffffffff81081ae5>] flush_work+0x105/0x1d0
[<ffffffff81081c39>] __cancel_work_timer+0x89/0x120
[<ffffffff81081d03>] cancel_delayed_work_sync+0x13/0x20
[<ffffffff812dba60>] disk_block_events+0x80/0x90
[<ffffffff811dee0e>] __blkdev_get+0x6e/0x4d0
[<ffffffff811df445>] blkdev_get+0x1d5/0x360
[<ffffffff811df67b>] blkdev_open+0x5b/0x80
[<ffffffff811a1cc7>] do_dentry_open+0x1a7/0x2e0
[<ffffffff811a1ef9>] vfs_open+0x39/0x70
[<ffffffff811b131d>] do_last+0x1ed/0x1270
[<ffffffff811b4082>] path_openat+0xc2/0x490
(Continue reading)

kbuild test robot | 13 Jun 12:22 2016
Picon

[target:nvmet-configfs-ng 30/35] drivers/nvme/target/configfs-ng.c:253:18: error: 'struct nvmet_port' has no member named 'port_binding_mutex'; did you mean 'port_binding_list'?

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git nvmet-configfs-ng
head:   b75ad796462431e38bba0fb04d277fd83c919575
commit: b57da10630e0fb2243e901f2df910c5c980e922e [30/35] nvmet/configfs-ng: Introduce struct nvmet_port_binding
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
        git checkout b57da10630e0fb2243e901f2df910c5c980e922e
        # save the attached .config to linux build tree
        make ARCH=i386 

Note: the target/nvmet-configfs-ng HEAD b75ad796462431e38bba0fb04d277fd83c919575 builds fine.
      It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/notifier.h:13:0,
                    from include/linux/memory_hotplug.h:6,
                    from include/linux/mmzone.h:737,
                    from include/linux/gfp.h:5,
                    from include/linux/kmod.h:22,
                    from include/linux/module.h:13,
                    from drivers/nvme/target/configfs-ng.c:5:
   drivers/nvme/target/configfs-ng.c: In function 'nvmet_port_disable':
>> drivers/nvme/target/configfs-ng.c:253:18: error: 'struct nvmet_port' has no member named
'port_binding_mutex'; did you mean 'port_binding_list'?
     mutex_lock(&port->port_binding_mutex);
                     ^
   include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
    #define mutex_lock(lock) mutex_lock_nested(lock, 0)
                                               ^~~~
(Continue reading)

Michael Cyr | 10 Jun 18:19 2016
Picon

Re: [PATCH v1] target: Fix Hang Tasks from Unsupported Scsi OP


On 6/10/16 8:56 AM, Bryant G. Ly wrote:
> On 2016-06-09 23:43, Nicholas A. Bellinger wrote:
>> Hey Bryant,
>>
>> On Wed, 2016-06-08 at 08:54 -0500, Bryant G. Ly wrote:
>>> If a Simple command is sent with an Unsupported SCSI Opcode (failure),
>>> target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE
>>> which then causes transport_generic_request_failure to decrement
>>> simple_cmds, due to call to transport_complete_task_attr.
>>> With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0.
>>> So when a subsequent command with an Ordered Task is sent, it causes
>>> a hang, since dev->simple_cmds is at -1. Thus to prevent Unsupported
>>> SCSI Opcode Failure from decrementing simple_cmds I added a check
>>> to skip transport_complete_task_attr for sense_reaons that are
>>> TCM_UNSUPPORTED_SCSI_OPCODE.
>>>
>>> I dont know if this is a proper fix, but it worked for me, let me
>>> know what you think Nick.
>>>
>>> Signed-off-by: Bryant G. Ly <bryantly <at> linux.vnet.ibm.com>
>>> ---
>>>  drivers/target/target_core_transport.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/target/target_core_transport.c 
>>> b/drivers/target/target_core_transport.c
>>> index 6c089af..4578fcf 100644
>>> --- a/drivers/target/target_core_transport.c
>>> +++ b/drivers/target/target_core_transport.c
(Continue reading)

Bryant G. Ly | 8 Jun 05:42 2016
Picon

[PATCH] target: Fix Hang Tasks from Unsupported Scsi OP

If a Simple command is sent with an Unsupported SCSI Opcode (failure),
target_setup_cmd_from_cdb returns with TCM_UNSUPPORTED_SCSI_OPCODE
which then causes transport_generic_request_failure to decrement
simple_cmds, due to call to transport_complete_task_attr.
With this dev->simple_cmds or dev->dev_ordered_sync is now -1, not 0.
So when a subsequent command with an Ordered Task is sent, it causes
a hang, since dev->simple_cmds is at -1. Thus to prevent Unsupported
SCSI Opcode Failure from decrementing simple_cmds I added a check
to skip transport_complete_task_attr for sense_reaons that are
TCM_UNSUPPORTED_SCSI_OPCODE.

I dont know if this is a proper fix, but it worked for me, let me
know what you think Nick.

Signed-off-by: Bryant G. Ly <bryantly <at> linux.vnet.ibm.com>
---
 drivers/target/target_core_transport.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 6c089af..e38aef0 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
 <at>  <at>  -1684,7 +1684,8  <at>  <at>  void transport_generic_request_failure(struct se_cmd *cmd,
 	/*
 	 * For SAM Task Attribute emulation for failed struct se_cmd
 	 */
-	transport_complete_task_attr(cmd);
+	if (sense_reason != TCM_UNSUPPORTED_SCSI_OPCODE)
+		transport_complete_task_attr(cmd);
(Continue reading)

Nicholas A. Bellinger | 8 Jun 05:34 2016

[RFC 0/2] nvme/loop: Add support for controllers-per-port model

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

Hi again folks,

So building on the nvmet/configfs-ng WIP posted yesterday:

http://marc.info/?l=linux-scsi&m=146528147018404&w=2

This series adds support for nvme/loop to utilize a nvme host
controller per nvmet_port, instead of a single hardcoded entry
for nvmet_port pointer access in nvme_loop_queue_rq().

It uses a struct device model following what we've done in
drivers/target/loopback to allow multiple host controllers
to co-exist under configfs, and is driven by the nvmet_port
configfs enable attribute.

Which means that any arbitary number of nvme-loop controllers
can now exist, and each nvmet_subsystem->ports_group can
enable/disable it's own loopback controller!

Here is how it looks in action for controller id 1 + 2:

root <at> scsi-mq:/sys/kernel/config/nvmet/subsystems# tree -if .
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon/namespaces
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon/namespaces/1
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon/namespaces/1/ramdisk1 -> ../../../../../target/core/rd_mcp_2/ramdisk1
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon/ports
./nqn.2003-01.org.linux-iscsi.NVMf.newsilicon/ports/loop
(Continue reading)

Nicholas A. Bellinger | 7 Jun 06:12 2016

[PATCH-v2 00/16] target: Allow backends to operate independent of se_cmd

From: Nicholas Bellinger <nab <at> linux-iscsi.org>

Hi Jens, HCH & Co,

This -v2 series introduces target_iostate + target_iomem descriptors
that abstract what existing target backend drivers require in order
to process I/O, sync_cache, write_same and unmap via sbc_ops.

The purpose is to allow existing target backend drivers from within
/sys/kernel/config/target/core/ to be accessed externally outside
of the existing /sys/kernel/config/target/$FABRIC/ configfs layout,
to operate independently of se_cmd + SCSI specific dependencies.

Namely, it's intended for the newly released nvme-target code to
utilize existing target-core backend drivers + T10-PI logic, without
requiring consumers to be under /sys/kernel/config/target/$FABRIC/
configfs layout.

Also included is a prerequisite bug-fix for target-core, and IBLOCK
optimization for eliminating the internal memory allocation.

v2 changes:

   - Convert sbc_ops->execute_unmap() capable backends to use
     __blkdev_issue_discard() asynchronous completion.
   - Convert IBLOCK to use inline bio + bvec, and use blk_poll()
     following nvmet/io-cmd for I/O submission.

Please review,

(Continue reading)

mchristi | 3 Jun 03:12 2016
Picon

[PATCH 1/1] target: fix max_unmap_lba_count calc overflow

From: Mike Christie <mchristi <at> redhat.com>

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie <mchristi <at> redhat.com>
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie <mchristi <at> redhat.com>
Cc: stable <at> vger.kernel.org

---
 drivers/target/target_core_device.c  | 8 +++++---
 drivers/target/target_core_file.c    | 3 +--
 drivers/target/target_core_iblock.c  | 3 +--
 include/target/target_core_backend.h | 2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
index a4046ca..6b42348 100644
(Continue reading)


Gmane