headers
Nicholas A. Bellinger | 17 May 2013 22:29

[PATCH] target: Use FD_MAX_SECTORS/FD_BLOCKSIZE for blockdevs using fileio

From: Andy Grover <agrover <at> redhat.com>

This is a <= v3.9 backport of upstream commit e3e84cda32170

------------------------------------------------------------------

We can still see the error reported in

https://patchwork.kernel.org/patch/2338981/

when using fileio backed by a block device.

I'm assuming this will get us past that error (from sbc_parse_cdb),
and also assuming it's OK to have our max_sectors be larger than
the block's queue max hw sectors?

Reported-by: Eric Harney <eharney <at> redhat.com>
Signed-off-by: Andy Grover <agrover <at> redhat.com>
Signed-off-by: Nicholas Bellinger <nab <at> linux-iscsi.org>
---
 drivers/target/target_core_file.c |   10 ++--------
 1 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/target/target_core_file.c b/drivers/target/target_core_file.c
index 17a6acb..ca4b219 100644
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
 <at>  <at>  -148,13 +148,8  <at>  <at>  static int fd_configure_device(struct se_device *dev)
 	 */
 	inode = file->f_mapping->host;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Grover | 16 May 2013 19:40
Picon
Favicon
Gravatar

[PATCHv2 0/12] target_core_pr.c cleanups

Changes from v1:
* Drop #4 "Only return 0 or -err from core_scsi3_check_implicit_release"
* Split up #10 (9 and 10 in this series)
* #13 "Add upcall to save aptpl state" held back for separate discussion

Regards -- Andy
Permalink | Reply | 18 comments |
headers
Paul Fitzgibbons | 16 May 2013 13:29
Favicon

FW: Restricting discovery of targets using LIO

Hi,

Can someone please let me know if there is a way of restricting target
discovery based upon IP addresses?

We currently use IET and use targets.allow to restrict this (We have
multiple VLANs on our SAN servers and do this to restrict traffic to
relevant subnets).

Does this functionality exist in LIO?

Rgds

Paul

Paul Fitzgibbons

Computer Operations Manager

Connect Internet Solutions Limited

http://www.connectinternetsolutions.com 

DDI: 0151 282 4302

Mobile: 07951 918 174

--

-- 
This e-mail (and any attachments) is private and confidential. If you have 
received it in error, please notify the sender immediately and delete it
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andy Grover | 16 May 2013 02:36
Picon
Favicon
Gravatar

[PATCH 0/13] target_core_pr.c cleanups and upcall API

This patchset refactors target_core_pr.c a bit, simplifying code flows when
possible and centralizing the handling of some memory allocations.

In addition, it adds a call to an optional userspace helper program to
handle saving PR APTPL state. Currently this is done by direct writes to
/var/target/pr/. The userspace upcall lets the OS decide where and how to
query and store this information, but in the absence of
'/sbin/target_notify', current behavior is maintained.

Regards -- Andy
Permalink | Reply | 20 comments |
headers
Nicholas A. Bellinger | 15 May 2013 23:50

[GIT PULL] target fixes for v3.10-rc2

Hi Linus,

The following are target fixes currently in the queue for v3.10-rc2.  

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git queue

A handful of fixes + minor changes this time around, along with one
important >= v3.9 regression fix for IBLOCK backends.  The highlights
include:

 - Use FD_MAX_SECTORS in FILEIO for block_device as well as files (agrover)
 - Fix processing of out-of-order CmdSNs with iSBD driver (shlomo)
 - Close long-standing target_put_sess_cmd() vs. core_tmr_abort_task() race
   with the addition of kref_put_spinlock_irqsave() (joern + greg-kh)
 - Fix IBLOCK WCE=1 + DPOFUA=1 backend WRITE regression in >= v3.9 (nab + bootc)

Note these four patches are CC'ed to stable.

Also, there is still some work left to be done on the active I/O
shutdown path in target_wait_for_sess_cmds() used by tcm_qla2xxx +
ib_isert fabrics that is still being discussed on the list, and will
hopefully be resolved soon.

Thank you,

--nab

Andy Grover (3):
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicholas A. Bellinger | 15 May 2013 08:36

[PATCH] target/iblock: Fix WCE=1 + DPOFUA=1 backend WRITE regression

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

This patch fixes a regression bug introduced in v3.9-rc1 where if the
underlying struct block_device for a IBLOCK backend is configured with
WCE=1 + DPOFUA=1 settings, the rw = WRITE assignment no longer occurs
in iblock_execute_rw(), and rw = 0 is passed to iblock_submit_bios()
in effect causing a READ bio operation to occur.

The offending commit is:

commit d0c8b259f8970d39354c1966853363345d401330
Author: Nicholas Bellinger <nab <at> linux-iscsi.org>
Date:   Tue Jan 29 22:10:06 2013 -0800

    target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status

Note the WCE=1 + DPOFUA=0, WCE=0 + DPOFUA=1, and WCE=0 + DPOFUA=0 cases
are not affected by this regression bug.

Reported-by: Chris Boot <bootc <at> bootc.net>
Cc: Chris Boot <bootc <at> bootc.net>
Reported-by: Hannes Reinecke <hare <at> suse.de>
Cc: Hannes Reinecke <hare <at> suse.de>
Signed-off-by: Nicholas Bellinger <nab <at> linux-iscsi.org>
---
 drivers/target/target_core_iblock.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c
index 07f5f94..aa1620a 100644
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Boot | 14 May 2013 22:22
Favicon
Gravatar

Read-only disks, but accepting writes

Hi folks,

I recently booted my home LIO FC target box (err, yes, home) with a
3.9.1 kernel, and found some very strange and erroneous behaviour from
the target code.

The target appears to accept writes but the data never makes it to disk.
When the same blocks are read again, the data is the same as it was
before the write.

This strange behaviour leads me to be able to boot a (FC initator)
machine correctly off the target, install a few updates, reboot - just
to find the machine snapped back to the state it was in before I booted
it up. I did this three times, and began to question my sanity!

Creating an LVM logical volume on the initiator machine fails:

parker bootc # lvcreate -L 50g -n test vg_parker
  Failed to activate new LV.
  Unable to deactivate failed new LV. Manual intervention required.

This appears to be because LVM writes metadata to the physical volume,
then reads it back to check everything is sane - and finds that it is not.

If I make lots of filesystem changes (such as dd if=/dev/zero
of=/var/tmp/zero.bin bs=1M) then drop caches with 'echo 3 >
/proc/sys/vm/drop_caches', I almost immediately get a journal abort on
the filesystem.

Note that if I reboot the machine it's snapped back to its previous
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joern Engel | 13 May 2013 22:30

[PATCH 0/3] target: Fix two races leading to use-after-free

In our testing we've encountered use-after-free bugs, usually in the
shape of double list_del, at a rate of 2-10 per week.  Patches 2 and 3
fix two races that can both lead to use-after-free and after applying
both of those patches, we have been bug-free for some weeks now.

Patch 1 is an unrelated trivial cleanup.  I just happened to spot it
while I was in the area.

Joern Engel (3):
  target: removed unused transport_state flag
  target: close target_put_sess_cmd() vs. core_tmr_abort_task() race v5
  target: simplify target_wait_for_sess_cmds()

 drivers/infiniband/ulp/srpt/ib_srpt.c  |    2 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.c     |    2 +-
 drivers/target/target_core_transport.c |   73 +++++++++-----------------------
 include/linux/kref.h                   |   33 +++++++++++++++
 include/target/target_core_base.h      |    3 --
 include/target/target_core_fabric.h    |    2 +-
 6 files changed, 57 insertions(+), 58 deletions(-)

--

-- 
1.7.10.4
Permalink | Reply | 13 comments |
headers
Nicholas A. Bellinger | 12 May 2013 01:30

[PATCH 0/3] target: misc patches for v3.10-rc0

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

Hi folks,

These are just a handful of minor patches to be included for v3.10-rc0.

This includes a new bit for RAMDISK_MCP backends that allows them to
function in NULLIO mode, which is useful for performance testing.

--nab

Nicholas Bellinger (3):
  target/rd: Add ramdisk bit for NULLIO operation
  iscsi-target: Fix typos in RDMAEXTENSIONS macro usage
  MAINTAINERS: Update target git tree URL

 MAINTAINERS                                    |    2 +-
 drivers/target/iscsi/iscsi_target_parameters.c |    8 ++++----
 drivers/target/iscsi/iscsi_target_parameters.h |    4 ++--
 drivers/target/target_core_rd.c                |   21 ++++++++++++++++++---
 drivers/target/target_core_rd.h                |    1 +
 5 files changed, 26 insertions(+), 10 deletions(-)

--

-- 
1.7.2.5
Permalink | Reply | 3 comments |
headers
Nicholas A. Bellinger | 10 May 2013 07:14

Re: LIO: crash while adding ramdisk to target

On Thu, 2013-05-09 at 16:29 -0700, Vishal Study wrote:
> Hello LIO users,
> 
> 
> This is my first time using LIO in kernel 3.4.x - running debian on
> MIPS platform, and trying to play with Ramdisks (to start experiments
> with)...

The output of /proc/version to identify the specific kernel version
would be helpful..
> 
> Following is what I'm doing:
> Create a ramdisk, 
> 
> Create a target
> add ramdisk to target
> 
> 
> As soon as I issue the last command, I get crash... 

> I would think this is a supported feature, but not sure why its
> crashing...

> Any pointers greatly appreciated.

> Thanks
> Vishal.

> root <at> mips:~# /etc/init.d/target start
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vishal Study | 9 May 2013 17:49
Picon

targetcli error

Hello targetcli experts,

I'm using Debian-7.0 on a MIPS platform and did following to get
targetcli running on my platform.

#apt-get install targetcli

It went ahead and downloaded a bunch of packages and all seemed to
have downloaded OK.

When I try to start targetcli, I get following error:
---------------------------------------------------------------------------------------------------------------------
# targetcli
Welcome to the targetcli shell:

 Copyright (c) 2011 by RisingTide Systems LLC.

Visit us at http://www.risingtidesystems.com.

Kernel module target_core_mod does not exists on disk and is not
loaded.
--------------------------------------------------------------------------------------------------------------------------

I have target_core_mod.ko locally and when I try to insmod it, it
gives following error:

# insmod target_core_mod.ko
target_core_mod: exports duplicate symbol __transport_register_session
(owned by kernel)
Error: could not insert module target_core_mod.ko: Invalid module format
(Continue reading)

Permalink | Reply | 1 comment |

Gmane