headers
FUJITA Tomonori | 1 Jun 2010 04:40
Picon
Gravatar

Re: Wrong DIF guard tag on ext2 write

On Mon, 31 May 2010 10:01:42 -0500
James Bottomley <James.Bottomley <at> suse.de> wrote:

> On Mon, 2010-05-31 at 10:20 -0400, Martin K. Petersen wrote:
> > >>>>> "Christof" == Christof Schmitt <christof.schmitt <at> de.ibm.com> writes:
> > 
> > Christof> Since the guard tags are created in Linux, it seems that the
> > Christof> data attached to the write request changes between the
> > Christof> generation in bio_integrity_generate and the call to
> > Christof> sd_prep_fn.
> > 
> > Yep, known bug.  Page writeback locking is messed up for buffer_head
> > users.  The extNfs folks volunteered to look into this a while back but
> > I don't think they have found the time yet.
> > 
> > 
> > Christof> Using ext3 or ext4 instead of ext2 does not show the problem.
> > 
> > Last I looked there were still code paths in ext3 and ext4 that
> > permitted pages to be changed during flight.  I guess you've just been
> > lucky.
> 
> Pages have always been modifiable in flight.  The OS guarantees they'll
> be rewritten, so the drivers can drop them if it detects the problem.
> This is identical to the iscsi checksum issue (iscsi adds a checksum
> because it doesn't trust TCP/IP and if the checksum is generated in
> software, there's time between generation and page transmission for the
> alteration to occur).  The solution in the iscsi case was not to
> complain if the page is still marked dirty.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Prakash, Sathya | 1 Jun 2010 09:55

Usage of scsi_get_lba.

I was trying to use scsi_get_lba to get the lba associated with a particular scsi_cmnd. I am able to get
proper values when I send I/O through dd or FS. But when I use the sg interface either sg_dd or sg_raw the
value I am getting through scsi_get_lba is not matching with the one in the CDB.

Do we need to have some change in sg module for handling this, or is there anything wrong in the way I access the
scsi_get_lba or sending command through sg?

Any suggestion or help is highly appreciated.

For I/O through DD
Jun  1 20:19:14 linux-eph1 kernel: sd 16:0:1:0: [sdc] CDB: Write(10): 2a 00 00 00 00 00 00 00 08 00
Jun  1 20:19:14 linux-eph1 kernel: LBA 0x0000000000000000

For a Non Zero LBA
Jun  1 20:19:35 linux-eph1 kernel: sd 16:0:1:0: [sdc] CDB: Write(10): 2a 00 00 00 0f f8 00 00 08 00
Jun  1 20:19:35 linux-eph1 kernel: LBA 0x0000000000000ff8

For I/O through sg_dd
Jun  1 20:19:45 linux-eph1 kernel: sd 16:0:1:0: [sg2] CDB: Write(10): 2a 00 00 00 0f ff 00 00 01 00
Jun  1 20:19:45 linux-eph1 kernel: LBA 0xffffffffffffffff

Jun  1 20:20:26 linux-eph1 kernel: sd 16:0:1:0: [sg2] CDB: Write(10): 2a 00 00 00 0f f8 00 00 08 00
Jun  1 20:20:26 linux-eph1 kernel: LBA 0xffffffffffffffff

Kernel Version
Linux linux-eph1 2.6.34-rc3-00626-gcee693e-dirty #3 SMP Mon May 24 16:41:33 IST 2010 x86_64 x86_64
x86_64 GNU/Linux

Thanks
Sathya
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicholas A. Bellinger | 1 Jun 2010 10:50

[PATCH 0/2] [tgt]: Add proper STGT <-> bs_sg passthrough v2

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

Greetings STGT folks,

Here is another go at a proper STGT bs_sg passthrough following input from Tomo and Boaz.
After taking another look, it ended up making alot more sense to split up the queue and
completion paths into struct scsi_lu->cmd_perform() and struct scsi_lu->cmd_done() callers
to support existing 'internal STGT port emulation' and proper struct scsi_cmd -> LUN passthrough
for bs_sg with TCM_Loop ports.

Following Boaz's recommendation, I will next have a look at extending bs_sg to support BSG so we
can actually pass things like SCSI Task Attrs and TMRs into TCM_Loop ports.  Until then, please have
a look and let me know if anything is missing.  These patches have been tested using STGT/iSCSI <->
TCM_Loop iSCSI Target Ports on v2.6.34 via Open-iSCSI with SPC-4 ALUA.  Here is the brief status:

tgtadm --lld iscsi --mode target --op show 
Target 1: iqn.2003-01.org.linux-iscsi.target.i686:sn.2aa7bad648f
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
        I_T nexus: 1
            Initiator: iqn.1993-08.org.debian:01:2dadf92d0ef
            Connection: 0
                IP Address: 172.16.201.129
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET     00010000
            SCSI SN: beaf10
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicholas A. Bellinger | 1 Jun 2010 10:50

[PATCH 1/2] [tgt]: Add proper STGT LUN backstore passthrough support

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

This patch adds two new queueing and completion function pointers to struct scsi_lu called ->cmd_perform()
and ->cmd_done() for handling existing internal STGT port emulation and the struct scsi_cmd
passthrough with bs_sg.c.  It retains the struct device_type_template->cmd_passthrough()
from the original patches, which still appears to be necessary for a device type to perform passthrough.
Also as before we modify the struct device_type_template sbc_template->cmd_passthrough() for sbc.c /
TYPE_DISK that we want to use passthrough for bs_sg LUNs.

For the setup path, we update tgt_device_create() to check if lu->cmd_perform() and lu->cmd_done()
have been set by struct backingstore_template->bs_init().  We expect bs_sg to setup these
pointers for us using the new target_cmd_perform_passthrough() and __cmd_done_passthrough() (see below).
Otherwise we setup the pointers following existing logic with target_cmd_perform() (also below) and
__cmd_done() for the non bs_sg case.

For the queue path and struct scsi_lu->cmd_perform() it made sense to split up target_cmd_queue()
into two functions, the original code at the tail of target_cmd_queue() now becomes
target_cmd_perform() and calls existing STGT port emulation code via cmd_enabled() -> scsi_cmd_perform().
A new function for passthrough has been added called target_cmd_perform_passthrough() that will do
struct scsi_lu->dev_type_template.cmd_passthrough() into the device type for bs_sg LUNs.

For the completion path and struct scsi_lu->cmd_done(), a new __cmd_done_passthrough()
has been added minus the original cmd_hlist_remove() and SCSI TASK attr checking in
__cmd_done().  __cmd_done() is used for the existing port emulation case, and modify the
two original users target_cmd_lookup() and abort_cmd() to call cmd->dev->cmd_done() instead.

This patch has been tested with STGT/iSCSI and TCM_Loop SPC-4 iSCSI Target Port emulation.

Signed-off-by: Nicholas A. Bellinger <nab <at> linux-iscsi.org>
---
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicholas A. Bellinger | 1 Jun 2010 10:50

[PATCH 2/2] [bs_sg]: Add bs_sg_init() for STGT LUN passthrough

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

This patch adds bs_sg_init() that is called from existing usr/target.c:tgt_device_create()
code via struct backingstore_template->bs_init() in order to setup the passthrough specific
queue and completion handlers for struct scsi_lu->cmd_perform() and ->cmd_done().

Signed-off-by: Nicholas A. Bellinger <nab <at> linux-iscsi.org>
---
 usr/bs_sg.c |   20 ++++++++++++++++++++
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/usr/bs_sg.c b/usr/bs_sg.c
index 8baa480..2fcb0d2 100644
--- a/usr/bs_sg.c
+++ b/usr/bs_sg.c
 <at>  <at>  -192,6 +192,25  <at>  <at>  static int init_sg_device(int fd)
 	return 0;
 }

+static int bs_sg_init(struct scsi_lu *lu)
+{
+	/*
+	 * Setup struct scsi_lu->cmd_perform() passthrough pointer
+	 * (if available) for the underlying device type.
+	 */
+	lu->cmd_perform = &target_cmd_perform_passthrough;
+	if (!(lu->cmd_perform)) {
+		eprintf("Unable to locate lu->cmd_perform() for bs_sg\n");
+		return -1;
+	}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Reinecke | 1 Jun 2010 11:19
Picon

[PATCH] scsi_error: blank out reservation conflict printk


When using SCSI reservations a 'reservation conflict' error
is actually expected. So we should better use the normal
SCSI_LOG_XXX functions to make it configurable for those
cases where we're actually interested in the error.

Signed-off-by: Hannes Reinecke <hare <at> suse.de>

diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index a5d630f..def540d 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
 <at>  <at>  -1509,8 +1509,8  <at>  <at>  int scsi_decide_disposition(struct scsi_cmnd *scmd)
 		return SUCCESS;

 	case RESERVATION_CONFLICT:
-		sdev_printk(KERN_INFO, scmd->device,
-			    "reservation conflict\n");
+		SCSI_LOG_ERROR_RECOVERY(3, sdev_printk(KERN_INFO, scmd->device,
+						"reservation conflict\n"));
 		return SUCCESS; /* causes immediate i/o error */
 	default:
 		return FAILED;
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Nicholas A. Bellinger | 1 Jun 2010 11:24

Re: [PATCH] scsi_error: blank out reservation conflict printk

On Tue, 2010-06-01 at 11:19 +0200, Hannes Reinecke wrote:
> When using SCSI reservations a 'reservation conflict' error
> is actually expected. So we should better use the normal
> SCSI_LOG_XXX functions to make it configurable for those
> cases where we're actually interested in the error.
> 
> Signed-off-by: Hannes Reinecke <hare <at> suse.de>
> 
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index a5d630f..def540d 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
>  <at>  <at>  -1509,8 +1509,8  <at>  <at>  int scsi_decide_disposition(struct scsi_cmnd *scmd)
>  		return SUCCESS;
>  
>  	case RESERVATION_CONFLICT:
> -		sdev_printk(KERN_INFO, scmd->device,
> -			    "reservation conflict\n");
> +		SCSI_LOG_ERROR_RECOVERY(3, sdev_printk(KERN_INFO, scmd->device,
> +						"reservation conflict\n"));
>  		return SUCCESS; /* causes immediate i/o error */
>  	default:
>  		return FAILED;

Makes perfect sense to me.

:-)

Acked-by: Nicholas A. Bellinger <nab <at> linux-iscsi.org>
(Continue reading)

Permalink | Reply | 0 comments |
headers
FUJITA Tomonori | 1 Jun 2010 11:42
Picon
Gravatar

Re: Usage of scsi_get_lba.

On Tue, 1 Jun 2010 13:25:24 +0530
"Prakash, Sathya" <Sathya.Prakash <at> lsi.com> wrote:

> I was trying to use scsi_get_lba to get the lba associated with a particular scsi_cmnd. I am able to get
proper values when I send I/O through dd or FS. But when I use the sg interface either sg_dd or sg_raw the
value I am getting through scsi_get_lba is not matching with the one in the CDB.
> 
> Do we need to have some change in sg module for handling this, or is there anything wrong in the way I access
the scsi_get_lba or sending command through sg?
> 
> Any suggestion or help is highly appreciated.

Seems that scsi_get_lba() can't use REQ_TYPE_BLOCK_PC commands (via
sg, bsg, etc) because request->__sector is not set.

We need to parse sc->cmnd like this.

The following scsi_get_transfer_info() is taken from scsi_debug. Some
(like libata) have similar code so it would make sense to convert it
to a library function.

diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index a5e885a..5bd697e 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
 <at>  <at>  -7,6 +7,7  <at>  <at> 
 #include <linux/types.h>
 #include <linux/timer.h>
 #include <linux/scatterlist.h>
+#include <scsi/scsi.h>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boaz Harrosh | 1 Jun 2010 12:49
Favicon
Gravatar

Re: Wrong DIF guard tag on ext2 write

On 06/01/2010 01:30 PM, Christof Schmitt wrote:
> On Mon, May 31, 2010 at 06:30:05PM +0300, Boaz Harrosh wrote:
>> On 05/31/2010 06:01 PM, James Bottomley wrote:
>>> On Mon, 2010-05-31 at 10:20 -0400, Martin K. Petersen wrote:
>>>>>>>>> "Christof" == Christof Schmitt <christof.schmitt <at> de.ibm.com> writes:
>>>>
>>>> Christof> Since the guard tags are created in Linux, it seems that the
>>>> Christof> data attached to the write request changes between the
>>>> Christof> generation in bio_integrity_generate and the call to
>>>> Christof> sd_prep_fn.
>>>>
>>>> Yep, known bug.  Page writeback locking is messed up for buffer_head
>>>> users.  The extNfs folks volunteered to look into this a while back but
>>>> I don't think they have found the time yet.
>>>>
>>>>
>>>> Christof> Using ext3 or ext4 instead of ext2 does not show the problem.
>>>>
>>>> Last I looked there were still code paths in ext3 and ext4 that
>>>> permitted pages to be changed during flight.  I guess you've just been
>>>> lucky.
>>>
>>> Pages have always been modifiable in flight.  The OS guarantees they'll
>>> be rewritten, so the drivers can drop them if it detects the problem.
>>> This is identical to the iscsi checksum issue (iscsi adds a checksum
>>> because it doesn't trust TCP/IP and if the checksum is generated in
>>> software, there's time between generation and page transmission for the
>>> alteration to occur).  The solution in the iscsi case was not to
>>> complain if the page is still marked dirty.
>>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane