Sagi Grimberg | 19 Oct 17:05 2014

[PATCH] srp-target: Rertry when QP creation fails with ENOMEM

From: Bart Van Assche <bvanassche <at> acm.org>

Retry with srp_sq_size/2.

Reported-by: Mark Lehrer <lehrer <at> gmail.com>
Signed-off-by: Bart Van Assche <bvanassche <at> acm.org>
Signed-off-by: Sagi Grimberg <sagig <at> mellanox.com>
---
 drivers/infiniband/ulp/srpt/ib_srpt.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index d28a8c2..d1042eb 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
 <at>  <at>  -2092,6 +2092,7  <at>  <at>  static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
 	if (!qp_init)
 		goto out;

+retry:
 	ch->cq = ib_create_cq(sdev->device, srpt_completion, NULL, ch,
 			      ch->rq_size + srp_sq_size, 0);
 	if (IS_ERR(ch->cq)) {
 <at>  <at>  -2115,6 +2116,13  <at>  <at>  static int srpt_create_ch_ib(struct srpt_rdma_ch *ch)
 	ch->qp = ib_create_qp(sdev->pd, qp_init);
 	if (IS_ERR(ch->qp)) {
 		ret = PTR_ERR(ch->qp);
+		if (ret == -ENOMEM) {
+			srp_sq_size /= 2;
+			if (srp_sq_size >= MIN_SRPT_SQ_SIZE) {
(Continue reading)

Rufe Glick | 15 Oct 22:48 2014
Picon

Inconsistencies in boolean parameter settings of targetcli

Hello all,

Just a feedback of a newcomer to the targetcli.

Some boolean parameters accept true or false, e.g. 'set global
auto_cd_after_create=true|false'; while other boolean parameters
accept 0 or 1, e.g. 'set attribute authentication=1|0'.

It doesn't bother me much, but it would be nice to eliminate these
inconsistencies. That'll make overall user experience a bit more
smooth and consistent.

The other thing of the same nature is paramter naming. Some of them
come with underscores, e.g. 'set global auto_cd_after_create' and
friends; while others come in camel case, e.g. 'set parameter
AuthMethod'.

Thanks,
Rufe
Steven Allen | 15 Oct 19:59 2014

[PATCH] iscsi-target: return the correct port in SendTargets

The fact that a target is published on the any address has no bearing on
which port(s) it is published. SendTargets should always send the
portal's port, not the port used for discovery.
---
 drivers/target/iscsi/iscsi_target.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/iscsi/iscsi_target.c b/drivers/target/iscsi/iscsi_target.c
index 260c3e1..ad85abe 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
 <at>  <at>  -3491,7 +3491,7  <at>  <at>  iscsit_build_sendtargets_response(struct iscsi_cmd *cmd,
 				len = sprintf(buf, "TargetAddress="
 					"%s:%hu,%hu",
 					inaddr_any ? conn->local_ip : np->np_ip,
-					inaddr_any ? conn->local_port : np->np_port,
+					np->np_port,
 					tpg->tpgt);
 				len += 1;

--

-- 
1.9.1

Jerome Martin | 15 Oct 18:51 2014

Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'


On 10/15/2014 06:21 PM, Andrew Watt wrote:
> Hi Jerome,
>  > Could you please give me the rtslib and targetcli versions you are
> using so I can take a look at the code?
> If only life were so easy:
> /> version
> Cannot find configshell version. The configshell package has probably
> not been built properly from either the git repository or a public tarball.
> Cannot find rtslib version. The rtslib package has probably not been
> built properly from either the git repository or a public tarball.
> Cannot find targetcli version. The targetcli package has probably not
> been built properly from either the git repository or a public tarball.
> I installed targetcli from the Ubuntu repositories (apt-get install
> targetcli), so I *think* that I'm using version 2.1-1 or targetcli
> (http://packages.ubuntu.com/trusty/targetcli), and version 2.2-1 or
> rtslib (http://packages.ubuntu.com/trusty/python-rtslib), but I could be
> wrong. There are several Python directories on this server (2.7, 3,
> 3.4), but firing up the Python interpreter brings me into Python 2.7.6.
> HTH,
> a.

Mmmmh. OK.
I guess I should have a word or two with the Ubuntu package maintainer.

Thanks for the info!
Andrew Watt | 15 Oct 14:11 2014
Picon

CDROM not recognised: 'Device is not a TYPE_DISK block device'

 Hello all,

I'm having a problem creating an iblock backstore from the CDROM drive in my HP Microserver.

The command:

create name=cdrom dev=/dev/sr0

Will return the following error:

Generating a wwn serial.
Device is not a TYPE_DISK block device.

I have been able to create a pscsi backstore to this device, and I can access it from my Windows 7 laptop,
although it can get confused and lock the drive tray if I mount it within the server - which is why I'm trying
the iblock configuration.

This behaviour is for a TSST Corp CDDVDW SH-24DBSCSI CDRom in a HP Microserver N54, with a clean install of
Ubuntu 14.04 server, and targetcli.

Any help would be greatly appreciated.

Thanks in advance,
a.
Suresh Babu Kandukuru | 15 Oct 08:16 2014
Picon

LIO filter driver to tap the data


Hi Group , I  need to write a LIO target driver which can tap all the incoming Data for a target lun and  give
one copy of that data to one of user space process in same machine of target lun. I have the LIO code with me . I
have chosen the FILEIO as back store . I have to tap all data coming into this target file and give that user
space process. Highly appreciate  any pointers , link or material on this topic . Thanks in advance.

/Suresh
Roland Dreier | 14 Oct 23:16 2014

[PATCH] target: Don't call TFO->write_pending if data_length == 0

From: Roland Dreier <roland <at> purestorage.com>

If an initiator sends a zero-length command (e.g. TEST UNIT READY) but
sets the transfer direction in the transport layer to indicate a
data-out phase, we still shouldn't try to transfer data.  At best it's
a NOP, and depending on the transport, we might crash on an
uninitialized sg list.

Reported-by: Craig Watson <craig.watson <at> vanguard-rugged.com>
Signed-off-by: Roland Dreier <roland <at> purestorage.com>
---
 drivers/target/target_core_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 7fa62fc93e0b..f7e659bd11ea 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
 <at>  <at>  -2296,7 +2296,7  <at>  <at>  transport_generic_new_cmd(struct se_cmd *cmd)
 	 * and let it call back once the write buffers are ready.
 	 */
 	target_add_to_state_list(cmd);
-	if (cmd->data_direction != DMA_TO_DEVICE) {
+	if (cmd->data_direction != DMA_TO_DEVICE || cmd->data_length == 0) {
 		target_execute_cmd(cmd);
 		return 0;
 	}
--

-- 
2.1.0

(Continue reading)

Rufe Glick | 14 Oct 05:37 2014
Picon

What does cache_dynamic_acls parameter do?

Hello all,

I'm just starting to learn the targetcli. Examples on internet that
set up 'TPG demo mode' along with authentication=0,
generate_noide_acls=1 and demo_mode_write_protect=0 parameters use
cache_dynamic_acls=1. I figured what the first three parameters do,
but I can't find information on the fourth - cache_dynamic_acls. Can
someone please explain me what does that parameter do. Also what are
dynamic acls?

Another question -- is there any better documentation available for
targetcli? I found the man page for targetcli version 2.1.fb34-1 that
comes with CentOS 7 pretty scanty. The man page from github repository
(https://github.com/agrover/targetcli-fb/blob/master/targetcli.8) is a
bit better, but still doesn't thoroughly describe all available
configuration parameters.

Thanks,
Rufe
Rickard Strandqvist | 12 Oct 19:55 2014
Picon

[PATCH] target: iscsi: iscsi_target_tpg.c: Cleaning up possible size overwriting in conjunction with sprintf

Changed same snprintf and sprintf to strlcpy and strlcat.
This will guarantee that the string size is not overwritten,
and they are significantly faster than sprintf also.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist <at> spectrumdigital.se>
---
 drivers/target/iscsi/iscsi_target_tpg.c |   16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_tpg.c b/drivers/target/iscsi/iscsi_target_tpg.c
index c3cb5c1..6fc8bfe 100644
--- a/drivers/target/iscsi/iscsi_target_tpg.c
+++ b/drivers/target/iscsi/iscsi_target_tpg.c
 <at>  <at>  -608,7 +608,6  <at>  <at>  int iscsit_tpg_set_initiator_node_queue_depth(
 int iscsit_ta_authentication(struct iscsi_portal_group *tpg, u32 authentication)
 {
 	unsigned char buf1[256], buf2[256], *none = NULL;
-	int len;
 	struct iscsi_param *param;
 	struct iscsi_tpg_attrib *a = &tpg->tpg_attrib;

 <at>  <at>  -626,34 +625,33  <at>  <at>  int iscsit_ta_authentication(struct iscsi_portal_group *tpg, u32 authentication)
 		return -EINVAL;

 	if (authentication) {
-		snprintf(buf1, sizeof(buf1), "%s", param->value);
+		strlcpy(buf1, param->value, sizeof(buf1));
 		none = strstr(buf1, NONE);
 		if (!none)
 			goto out;
(Continue reading)

Nicholas A. Bellinger | 8 Oct 08:11 2014

Re: [PATCH] target/file: fix inclusive vfs_fsync_range() end

On Mon, 2014-10-06 at 16:40 -0700, Zach Brown wrote:
> Both of the file target's calls to vfs_fsync_range() got the end offset
> off by one.  The range is inclusive, not exclusive.  It would sync a bit
> more data than was required.
> 
> The sync path already tested the length of the range and fell back to
> LLONG_MAX so I copied that pattern in the rw path.
> 
> This is untested. I found the errors by inspection while following other
> code.
> 
> Signed-off-by: Zach Brown <zab <at> zabbo.net>
> ---
>  drivers/target/target_core_file.c | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
> index 7d6cdda..176588f 100644
> --- a/drivers/target/target_core_file.c
> +++ b/drivers/target/target_core_file.c
>  <at>  <at>  -415,7 +415,7  <at>  <at>  fd_execute_sync_cache(struct se_cmd *cmd)
>  	} else {
>  		start = cmd->t_task_lba * dev->dev_attrib.block_size;
>  		if (cmd->data_length)
> -			end = start + cmd->data_length;
> +			end = start + cmd->data_length - 1;
>  		else
>  			end = LLONG_MAX;
>  	}
>  <at>  <at>  -680,7 +680,12  <at>  <at>  fd_execute_rw(struct se_cmd *cmd, struct scatterlist *sgl, u32 sgl_nents,
(Continue reading)

Nicholas A. Bellinger | 8 Oct 08:01 2014

Re: [PATCH] iser-target: Disable TX completion interrupt coalescing

On Tue, 2014-10-07 at 09:58 +0300, Sagi Grimberg wrote:
> On 10/6/2014 5:15 AM, Nicholas A. Bellinger wrote:
> > From: Nicholas Bellinger <nab <at> linux-iscsi.org>
> >
> > This patch explicitly disables TX completion interrupt coalescing logic
> > in isert_put_response() and isert_put_datain() that was originally added
> > as an efficiency optimization in commit 95b60f07.
> >
> > It has been reported that this change can trigger ABORT_TASK timeouts
> > under certain small block workloads, where disabling coalescing was
> > required for stability.  According to Sagi, this doesn't impact
> > overall performance, so go ahead and disable it for now.
> >
> > Reported-by: Moussa Ba <moussaba <at> micron.com>
> > Cc: Moussa Ba <moussaba <at> micron.com>
> > Reported-by: Sagi Grimberg <sagig <at> dev.mellanox.co.il>
> > Cc: Sagi Grimberg <sagig <at> dev.mellanox.co.il>
> > Cc: <stable <at> vger.kernel.org> # 3.13+
> > Signed-off-by: Nicholas Bellinger <nab <at> linux-iscsi.org>
> > ---
> >   drivers/infiniband/ulp/isert/ib_isert.c |    4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/ulp/isert/ib_isert.c b/drivers/infiniband/ulp/isert/ib_isert.c
> > index 40969b6..f719112 100644
> > --- a/drivers/infiniband/ulp/isert/ib_isert.c
> > +++ b/drivers/infiniband/ulp/isert/ib_isert.c
> >  <at>  <at>  -2183,7 +2183,7  <at>  <at>  isert_put_response(struct iscsi_conn *conn, struct iscsi_cmd *cmd)
> >   		isert_cmd->tx_desc.num_sge = 2;
> >   	}
(Continue reading)


Gmane