Sagi Grimberg | 29 Jun 17:32 2015

[PATCH] target/spc: Set SPT correctly in Extended INQUIRY Data VPD page

LIO supports protection types 1,3 so setting a had-coded SPT=3
is fine for now.

Signed-off-by: Sagi Grimberg <sagig <at> mellanox.com>
---
 drivers/target/target_core_spc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 08114bf..aaf1964 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
 <at>  <at>  -457,6 +457,9  <at>  <at>  spc_emulate_evpd_86(struct se_cmd *cmd, unsigned char *buf)
 			buf[4] = 0x4;
 	}

+	/* logical unit supports type 1 and type 3 protection */
+	buf[4] |= (0x3 << 3);
+
 	/* Set HEADSUP, ORDSUP, SIMPSUP */
 	buf[5] = 0x07;

--

-- 
1.8.4.3

Sagi Grimberg | 29 Jun 12:08 2015

[PATCH for-next] target: Use struct t10_pi_tuple

Its not a good idea to keep target specific definition of
the same t10-pi tuple.

Signed-off-by: Sagi Grimberg <sagig <at> mellanox.com>
---
 drivers/target/target_core_device.c |  2 +-
 drivers/target/target_core_sbc.c    | 10 +++++-----
 include/target/target_core_base.h   |  7 +------
 3 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
index d9f52da..2386529 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
 <at>  <at>  -754,7 +754,7  <at>  <at>  struct se_device *target_alloc_device(struct se_hba *hba, const char *name)
 	dev->dev_link_magic = SE_DEV_LINK_MAGIC;
 	dev->se_hba = hba;
 	dev->transport = hba->backend->ops;
-	dev->prot_length = sizeof(struct se_dif_v1_tuple);
+	dev->prot_length = sizeof(struct t10_pi_tuple);
 	dev->hba_index = hba->hba_index;

 	INIT_LIST_HEAD(&dev->dev_list);
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 9a5e7d0..84807e1 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
 <at>  <at>  -1191,7 +1191,7  <at>  <at>  void
 sbc_dif_generate(struct se_cmd *cmd)
 {
(Continue reading)

Sagi Grimberg | 29 Jun 12:07 2015

[PATCH for-next 1/2] target/pr: Fix possible uninitialized variable usage

Triggered a compilation warning.

Fixes: 2650d71e2 target: move transport ID handling to the core
Signed-off-by: Sagi Grimberg <sagig <at> mellanox.com>
---
 drivers/target/target_core_pr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/target_core_pr.c b/drivers/target/target_core_pr.c
index 7403b03..410b75f 100644
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
 <at>  <at>  -1474,7 +1474,7  <at>  <at>  core_scsi3_decode_spec_i_port(
 	LIST_HEAD(tid_dest_list);
 	struct pr_transport_id_holder *tidh_new, *tidh, *tidh_tmp;
 	unsigned char *buf, *ptr, proto_ident;
-	const unsigned char *i_str;
+	const unsigned char *i_str = NULL;
 	char *iport_ptr = NULL, i_buf[PR_REG_ISID_ID_LEN];
 	sense_reason_t ret;
 	u32 tpdl, tid_len = 0;
--

-- 
1.8.4.3

Ahmed Al-Mehdi | 22 Jun 04:19 2015
Picon

backstore created in "deactivated" state

Hello,

I am trying to setup a loopback setup using "targetcli".  I am
following the steps mentioned at site -
http://linux-iscsi.org/wiki/Loopback

I issued the following commands:

/backstores/fileio> create  dev_file_disk file_disk 10mb
/loopback> create
Created target naa.5001405f29525ad4.

However, I see the fileio backstore created in "deactivated" state:

  | o- fileio ..................................................................
[Storage Objects: 1]
  | | o- dev_file_disk .................... [file_disk (10.0MiB)
write-back deactivated]

How can I activated the fileio backstore (dev_file_disk)?  My
understanding, if all is setup right (fileio backstore active), a new
entry /dev/sdx  will be created.  Is that right?

I have a related question.  If I create multiple fileio and/or block
backstore.  Is there a way I can control which of the fileio/blockio
are created a loopback, rather than all of them.

Thank you,
Ahmed.
(Continue reading)

Hetz Ben Hamo | 20 Jun 22:25 2015

VAAI not showing

Hi,

(I hope I'm posting to the right list..)

I'm using CentOS 7 with targetcli that ships with it. I created an
iSCSI target with block device (ZFS's ZVol) and connected it to ESXI
5.5. So far, so good.

When I'm trying to check the ESXi shell if the new iSCSI target is
VAAI supported, I get on all the the 5 items "unsupported", here is
the output:

~ # esxcli storage core device vaai status get
naa.6001405343708cb07a04321927d54acd
   VAAI Plugin Name:
   ATS Status: unsupported
   Clone Status: unsupported
   Zero Status: supported
   Delete Status: unsupported

I tried to Google this issue a bit and all I could find to set some
attributes in fileIO, but I'm using Block, and the command "attribute"
with the targetcli doesn't work.

Any suggestions?

Thanks
Christoph Hellwig | 19 Jun 15:14 2015
Picon

[PATCH 1/3] target: consolidate version defines

Signed-off-by: Christoph Hellwig <hch <at> lst.de>
---
 drivers/target/target_core_configfs.c | 6 +++---
 drivers/target/target_core_file.c     | 2 +-
 drivers/target/target_core_iblock.c   | 2 +-
 drivers/target/target_core_pscsi.c    | 2 +-
 drivers/target/target_core_rd.c       | 2 +-
 include/target/target_core_base.h     | 3 +--
 include/target/target_core_configfs.h | 1 -
 7 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c
index 68addbc..6003921a 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
 <at>  <at>  -103,7 +103,7  <at>  <at>  static ssize_t target_core_attr_show(struct config_item *item,
 				      char *page)
 {
 	return sprintf(page, "Target Engine Core ConfigFS Infrastructure %s"
-		" on %s/%s on "UTS_RELEASE"\n", TARGET_CORE_CONFIGFS_VERSION,
+		" on %s/%s on "UTS_RELEASE"\n", TARGET_CORE_VERSION,
 		utsname()->sysname, utsname()->machine);
 }

 <at>  <at>  -3235,7 +3235,7  <at>  <at>  static ssize_t target_core_hba_show_attr_hba_info(
 {
 	return sprintf(page, "HBA Index: %d plugin: %s version: %s\n",
 			hba->hba_id, hba->backend->ops->name,
-			TARGET_CORE_CONFIGFS_VERSION);
+			TARGET_CORE_VERSION);
(Continue reading)

Christoph Hellwig | 19 Jun 15:10 2015
Picon

[PATCH 1/3] target: replace se_cmd->execute_rw with a protocol_data field

Instead of leaking this SBC read/write implementation detail just add an
opaqueue protocol specific pointer to struct se_cmd that we can assign
the sbc_ops vector to.

Signed-off-by: Christoph Hellwig <hch <at> lst.de>
---
 drivers/target/target_core_sbc.c  | 20 +++++++-------------
 include/target/target_core_base.h |  3 +--
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 31b2ae3..287843e 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
 <at>  <at>  -381,7 +381,9  <at>  <at>  out:
 static sense_reason_t
 sbc_execute_rw(struct se_cmd *cmd)
 {
-	return cmd->execute_rw(cmd, cmd->t_data_sg, cmd->t_data_nents,
+	struct sbc_ops *ops = cmd->protocol_data;
+
+	return ops->execute_rw(cmd, cmd->t_data_sg, cmd->t_data_nents,
 			       cmd->data_direction);
 }

 <at>  <at>  -560,6 +562,7  <at>  <at>  out:
 static sense_reason_t
 sbc_compare_and_write(struct se_cmd *cmd)
 {
+	struct sbc_ops *ops = cmd->protocol_data;
(Continue reading)

Hannes Reinecke | 19 Jun 08:40 2015
Picon

Merging se_dev_entry and se_lun?

Hi Nic,

having done the patch to export 'write_protect' for demo-mode LUNs
I've came across one puzzling item:

struct se_lun uses a list to refer to the underlying se_dev_entry
structures. Which I found rather curious, as from my understanding
'se_lun' is the structure for the mapped LUN (ie the LUN visible to
the initiator) and 'se_dev_entry' is the underlying physical device
as visible to the LUN.
As such I would have expected a 1:1 relationship between both, ie a
simple pointer from se_lun to se_dev_entry.

Having a list here implies that 'se_lun' can have _several_
se_dev_entry structure attached to it, which I found rather curious.

Can you give me an example where this might be the case?
Or can we replace the list with a simple pointer or even merge both?

Reason I'm asking is the lun_access / dev_flags field; it really
looks like it being a duplicate (I would judge 'write_protect' to be
a property of the mapped LUN, and not of the underlying device),
but in either case having it in both places requires a
synchronisation between both, as for demo-mode LUNs we can only
change it via se_lun, and for others we have to change it via the
se_dev_entry.

Cheers,

Hannes
(Continue reading)

Hannes Reinecke | 18 Jun 11:43 2015
Picon

[PATCH 0/8] tcm_loop updates

Hi Nic,

As tcm_loop claims to be a SAS HBA I thought it a good idea to
hook it into the SAS transport class, so that we have the entire
(virtual) SAS topology in sysfs now.
And even lsscsi is happy:

# lsscsi -H -t
[10]    tcm_loopback  sas:0x6001405cc9332c5a
# lsscsi -t
[10:0:0:0]   disk    sas:0x6001405e41925ad3          /dev/sdf 
[10:0:1:0]   disk    sas:0x6001405e41925ad3          /dev/sdg 

I've also included some pending fixes / updates I did for
LIO target, mostly done to reproduce issues I've been facing:
- Disallow READ CAPACITY in standby
  This is a long-standing issue with the linux SCSI stack and
  multipathing, both assuming that READ CAPACITY will always
  succeed. With that patch we can finally debug and fix this.
- Export the 'write_protect' attribute for demo-mode LUNs
- Some more UAs to be issued

As usual, reviews and comments are welcome.

Hannes Reinecke (8):
  tcm_loop: Hook into SAS transport class
  tcm_loop: Add SAS transport topology
  tcm_loop: Remove SAS vestigies
  tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA
  tcm_loop: Rescan SCSI target on transport online
(Continue reading)

Sebastian Herbszt | 18 Jun 00:56 2015
Picon
Picon

[PATCH] Documentation/target: Fix tcm_mod_builder.py build breakage

Fix build breakage introduced by commit 9ac8928e6a3e ("target: simplify the
target template registration API").

Signed-off-by: Sebastian Herbszt <herbszt <at> gmx.de>
---

diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py
index 2ba71ce..04e5fc6 100755
--- a/Documentation/target/tcm_mod_builder.py
+++ b/Documentation/target/tcm_mod_builder.py
 <at>  <at>  -371,7 +371,7  <at>  <at>  def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name):

 	buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops = {\n"
 	buf += "	.module				= THIS_MODULE,\n"
-	buf += "	.name				= " + fabric_mod_name + ",\n"
+	buf += "	.name				= \"" + fabric_mod_name + "\",\n"
 	buf += "	.get_fabric_proto_ident		= " + fabric_mod_name + "_get_fabric_proto_ident,\n"
 	buf += "	.get_fabric_name		= " + fabric_mod_name + "_get_fabric_name,\n"
 	buf += "	.get_fabric_proto_ident		= " + fabric_mod_name + "_get_fabric_proto_ident,\n"
 <at>  <at>  -416,17 +416,17  <at>  <at>  def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name):
 	buf += "	.fabric_make_nodeacl		= " + fabric_mod_name + "_make_nodeacl,\n"
 	buf += "	.fabric_drop_nodeacl		= " + fabric_mod_name + "_drop_nodeacl,\n"
 	buf += "\n"
-	buf += "	.tfc_wwn_attrs			= " + fabric_mod_name + "_wwn_attrs;\n"
+	buf += "	.tfc_wwn_attrs			= " + fabric_mod_name + "_wwn_attrs,\n"
 	buf += "};\n\n"

 	buf += "static int __init " + fabric_mod_name + "_init(void)\n"
 	buf += "{\n"
-	buf += "	return target_register_template(" + fabric_mod_name + "_ops);\n"
(Continue reading)

Nicholas A. Bellinger | 17 Jun 08:45 2015

Re: [PATCH] target/user: Fix inconsistent kmap_atomic/kunmap_atomic

On Mon, 2015-06-15 at 13:07 +0300, Sagi Grimberg wrote:
> On 6/12/2015 8:25 PM, Andy Grover wrote:
> > On 06/11/2015 09:58 AM, Sagi Grimberg wrote:
> >> Pointers that are mapped by kmap_atomic() + offset must
> >> be unmapped without the offset. That would cause problems
> >> if the SG element length exceeds the PAGE_SIZE limit.
> >>
> >> Signed-off-by: Sagi Grimberg <sagig <at> mellanox.com>
> >> ---
> >>   drivers/target/target_core_user.c |   14 ++++++++------
> >>   1 files changed, 8 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/target/target_core_user.c
> >> b/drivers/target/target_core_user.c
> >> index 949e616..078ef6e 100644
> >> --- a/drivers/target/target_core_user.c
> >> +++ b/drivers/target/target_core_user.c
> >>  <at>  <at>  -260,7 +260,8  <at>  <at>  static void alloc_and_scatter_data_area(struct
> >> tcmu_dev *udev,
> >>
> >>           /* Uh oh, we wrapped the buffer. Must split sg across 2
> >> iovs. */
> >>           if (sg->length != copy_bytes) {
> >> -            from += copy_bytes;
> >> +            void *from_skip = from + copy_bytes;
> >> +
> >>               copy_bytes = sg->length - copy_bytes;
> >>
> >>               (*iov)->iov_len = copy_bytes;
> >>  <at>  <at>  -270,7 +271,7  <at>  <at>  static void alloc_and_scatter_data_area(struct
(Continue reading)


Gmane