Varun Prakash | 21 Jul 19:27 2016

[net-next v3 0/6] common library for Chelsio drivers.

Hi,

 This patch series adds common library module(libcxgb.ko)
 for Chelsio drivers to remove duplicate code.

 This series moves common iSCSI DDP Page Pod manager
 code from cxgb4.ko to libcxgb.ko, earlier this code
 was used by only cxgbit.ko now it is used by
 three Chelsio iSCSI drivers cxgb3i, cxgb4i, cxgbit.

 In future this module will have common connection
 management and hardware specific code that can
 be shared by multiple Chelsio drivers(cxgb4,
 csiostor, iw_cxgb4, cxgb4i, cxgbit).

 Please review.

 Thanks

-v3
- removed unused module init and exit functions.

-v2
- updated CONFIG_CHELSIO_LIB to an invisible option
- changed libcxgb.ko module license from GPL to Dual BSD/GPL

Varun Prakash (6):
  libcxgb: add library module for Chelsio drivers
  cxgb3i,cxgb4i,libcxgbi: remove iSCSI DDP support
  cxgb4i,libcxgbi: add iSCSI DDP support
(Continue reading)

Hannes Reinecke | 19 Jul 15:01 2016
Picon

[PATCH] tcm_fc: set and unset FCP_SPPF_TARG_FCN

When registering and unregistering as an target port we should
be setting the FC-4 service params correctly.

Signed-off-by: Hannes Reinecke <hare <at> suse.com>
---
 drivers/target/tcm_fc/tfc_sess.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/target/tcm_fc/tfc_sess.c b/drivers/target/tcm_fc/tfc_sess.c
index f5186a7..6ffbb60 100644
--- a/drivers/target/tcm_fc/tfc_sess.c
+++ b/drivers/target/tcm_fc/tfc_sess.c
 <at>  <at>  -91,6 +91,7  <at>  <at>  static void ft_tport_delete(struct ft_tport *tport)

 	ft_sess_delete_all(tport);
 	lport = tport->lport;
+	lport->service_params &= ~FCP_SPPF_TARG_FCN;
 	BUG_ON(tport != lport->prov[FC_TYPE_FCP]);
 	RCU_INIT_POINTER(lport->prov[FC_TYPE_FCP], NULL);

 <at>  <at>  -110,6 +111,7  <at>  <at>  void ft_lport_add(struct fc_lport *lport, void *arg)
 {
 	mutex_lock(&ft_lport_lock);
 	ft_tport_get(lport);
+	lport->service_params |= FCP_SPPF_TARG_FCN;
 	mutex_unlock(&ft_lport_lock);
 }

--

-- 
1.8.5.6
(Continue reading)

Varun Prakash | 16 Jul 19:19 2016

[net-next v2 0/6] common library for Chelsio drivers

Hi,

 This patch series adds common library module(libcxgb.ko)
 for Chelsio drivers to remove duplicate code.

 This series moves common iSCSI DDP Page Pod manager
 code from cxgb4.ko to libcxgb.ko, earlier this code
 was used by only cxgbit.ko now it is used by
 three Chelsio iSCSI drivers cxgb3i, cxgb4i, cxgbit.

 In future this module will have common connection
 management and hardware specific code that can
 be shared by multiple Chelsio drivers(cxgb4,
 csiostor, iw_cxgb4, cxgb4i, cxgbit).

 Please review.

 Thanks

-v2
- updated CONFIG_CHELSIO_LIB to an invisible option
- changed libcxgb.ko module license from GPL to Dual BSD/GPL

Varun Prakash (6):
  libcxgb: add library module for Chelsio drivers
  cxgb3i,cxgb4i,libcxgbi: remove iSCSI DDP support
  cxgb4i,libcxgbi: add iSCSI DDP support
  cxgb3i: add iSCSI DDP support
  libcxgb: export ppm release and tagmask set api
  cxgb3i,cxgb4i: fix symbol not declared sparse warning
(Continue reading)

冯力 | 6 Jul 12:04 2016
Picon

Oops when connecting to iscsi.

When I'm connecting iscsi target, I get this stack ocasionally.

I don't reproduct it now.

Anyone have idea?

 $ uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-1 (2016-03-06)
x86_64 GNU/Linux

#dmesg

[ 1160.788676] sd 16:0:0:0: [sde] Attached SCSI disk
[ 1383.962626] target_core_get_fabric() failed for usb_gadget
[ 1404.788910] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x1b,
sending CHECK_CONDITION.
[ 1404.858451] BUG: unable to handle kernel NULL pointer dereference
at 00000000000001f8
[ 1404.858911] IP: [<ffffffffa05ee5d8>]
iscsi_target_login_thread+0x728/0x10b0 [iscsi_target_mod]
[ 1404.859746] PGD 230c29067 PUD 232060067 PMD 0
[ 1404.859963] Oops: 0000 [#1] SMP
[ 1404.860154] Modules linked in: crc32c_generic tcm_loop tcm_qla2xxx
qla2xxx iscsi_target_mod ib_srpt vhost_scsi vhost tcm_fc libfc
scsi_transport_fc scsi_tgt target_core_file target_core_iblock
target_core_pscsi target_core_mod configfs nbd
vmw_vsock_vmci_transport vsock bridge stp llc vmhgfs(O) snd_ens1371
snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd
vmw_balloon evdev soundcore ac97_bus gameport ppdev pcspkr sg psmouse
serio_raw parport_pc vmwgfx parport battery ttm drm_kms_helper drm
(Continue reading)

Sumit Rai | 3 Jul 15:54 2016
Picon

Re [PATCH RFC]: LIO seems to use SCSI Allocation Length instead of SPDTL for calculating ResidualCount

> From: Sumit Rai <sumit.rai <at> calsoftinc.com>
> Subject: LIO seems to use SCSI Allocation Length instead of SPDTL for calculating ResidualCount
> Date: June 22, 2016 at 7:43:50 PM GMT+5:30
> To: target-devel <at> vger.kernel.org
> 
> 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:
(Continue reading)

Markus Mayer | 1 Jul 01:50 2016

[PATCH 0/6] lib: string: add function strtolower()

This series introduces a new generic function strtolower(), which
converts strings to lowercase in-place, overwriting the original
string. This kind of functionality is needed in several places in the
kernel. Right now, everybody seems to be implementing their own copy of
this function. So, we replace several custom "strtolower"
implementations with this new library function.

Another driver that also makes use of this function will be submitted
upstream shortly, which prompted this whole exercise.

The changes made here have been compile-tested, but not tried out, due
to lack of required hardware.

This series is based on v4.7-rc5.

Markus Mayer (6):
  lib: string: add function strtolower()
  drm/nouveau/core: make use of new strtolower() function
  ACPICA: make use of new strtolower() function
  ACPI / device_sysfs: make use of new strtolower() function
  staging: speakup: replace spk_strlwr() with strtolower()
  iscsi-target: replace iscsi_initiatorname_tolower() with strtolower()

 drivers/acpi/acpica/utnonansi.c              | 13 +------------
 drivers/acpi/device_sysfs.c                  |  4 +---
 drivers/gpu/drm/nouveau/nvkm/core/firmware.c |  7 +------
 drivers/staging/speakup/kobjects.c           |  2 +-
 drivers/staging/speakup/main.c               |  2 +-
 drivers/staging/speakup/speakup.h            |  1 -
 drivers/staging/speakup/varhandlers.c        | 12 ------------
(Continue reading)

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)


Gmane