Re: [PATCH] target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status

[Asias He]

On 01/30/2013 02:57 PM, Nicholas A. Bellinger wrote:
> From: Nicholas Bellinger 
> 
> This patch allows IBLOCK to check block hints in request_queue->flush_flags
> when reporting current backend device WriteCacheEnabled status to a remote
> SCSI initiator port.
> 
> This is done via a se_subsystem_api->get_write_cache() call instead of a
> backend se_device creation time flag, as we expect REQ_FLUSH bits to possibly
> change from an underlying blk_queue_flush() by the SCSI disk driver, or
> internal raw struct block_device driver usage.
> 
> Also go ahead and update iblock_execute_rw() bio I/O path code to use
> REQ_FLUSH + REQ_FUA hints when determining WRITE_FUA usage, and make SPC
> emulation code use a spc_check_dev_wce() helper to handle both types of
> cases for virtual backend subsystem drivers.
> 
> Reported-by: majianpeng 
> Cc: majianpeng 
> Cc: Christoph Hellwig 
> Cc: Jens Axboe 
> Cc: James Bottomley 
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/target/target_core_device.c  |6 ++
>  drivers/target/target_core_iblock.c  |   31 +++
>  drivers/target/target_core_spc.c |   21 ++---
>  include/target/target_core_backend.h |1 +
>  4 files changed, 48 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/target/target_core_device.c 
> b/drivers/target/target_core_device.c
> index e269510..1d71930 100644
> --- a/drivers/target/target_core_device.c
> +++ b/drivers/target/target_core_device.c
> @@ -772,6 +772,12 @@ int se_dev_set_emulate_write_cache(struct se_device 
> *dev, int flag)
>   pr_err("emulate_write_cache not supported for pSCSI\n");
>   return -EINVAL;
>   }
> + if (dev->transport->get_write_cache != NULL) {

one nit:

if (dev->transport->get_write_cache) {

?

> + pr_warn("emulate_write_cache cannot be changed when underlying"
> + " HW reports WriteCacheEnabled, ignoring request\n");
> + return 0;
> + }
> +
>   dev->dev_attrib.emulate_write_cache = flag;
>   pr_debug("dev[%p]: SE Device WRITE_CACHE_EMULATION flag: %d\n",
>   dev, dev->dev_attrib.emulate_write_cache);
> diff --git a/drivers/target/target_core_iblock.c 
> b/drivers/target/target_core_iblock.c
> index b526d23..fc45683 100644
> --- a/drivers/target/target_core_iblock.c
> +++ b/drivers/target/target_core_iblock.c
> @@ -154,6 +154,7 @@ static int iblock_configure_device(struct se_device *dev)
>  
>   if (blk_queue_nonrot(q))
>   dev->dev_attrib.is_nonrot = 1;
> +
>   return 0;
>  
>  out_free_bioset:
> @@ -654,20 +655,24 @@ iblock_execute_rw(struct se_cmd *cmd)
>   u32 sg_num = sgl_nents;
>   sector_t block_lba;
>   unsigned bio_cnt;
> - int rw;
> + int rw = 0;
>   int i;
>  
>   if (data_direction == DMA_TO_DEVICE) {
> + struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
> + struct request_queue *q = bdev_get_queue(ib_dev->ibd_bd);
>   /*
> -  * Force data to disk if we pretend to not have a volatile
> -  * write cache, or the initiator set the Force Unit Access bit.
> +  * Force writethrough using WRITE_FUA if a volatile write cache
> +  * is not enabled, or if initiator set the Force Unit Access 
> bit.
>*/
> - if (dev->dev_attrib.emulate_write_cache == 0 ||
> - (dev->dev_attrib.emulate_fua_write > 0 &&
> -  (cmd->se_cmd_flags & SCF_FUA)))
> - rw = WRITE_FUA;
> - else
> + if (q->flush_flags & REQ_FUA) {
> + if (cmd->se_cmd_flags & SCF_FUA)
> + rw = WRITE_FUA;
> + else if (!(q->flush_flags & REQ_FLUSH))
> + rw = WRITE_FUA;
> + } else {
>   rw = WRITE;
> + }
>   } else {
>   rw = READ;
>   }
> @@ -774,6 +779,15 @@ iblock_parse_cdb(struct se_cmd *cmd)
>   return sbc_parse_cdb(cmd, &iblock_sbc_ops);
>  }
>  
> +bool iblock_get_write_cache(struct se_device *dev)
> +{
> + struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
> + struct block_device *bd = ib_dev->ibd_bd;
> + struct request_queue *q = bdev_get_queue(bd);
> +
> + return (q->flush_flags & REQ_FLUSH);

no need of the ().

> +}
> +
>  static struct se_subsystem_api iblock_template = {
>   .name   = "iblock",
>   .inquiry_prod   = "IBLOCK",
> @@ -790,6 +804,7 @@ static struct se_subsystem_api iblock_template = {
>   .show_configfs_dev_params = iblock_show_configfs_dev_params,
>   .get_device_type= sbc_get_device_type,
>   .get_blocks = iblock_get_blocks,
> + .get_write_cache= iblock_get_write_cache,
>  };
>  
>  static int __init iblock_module_init(void)
> diff --git a/drivers/target/target_core_spc.c 
> b/drivers/target

Re: Re: [PATCH] target: For iblock at default writecache enable.

[Nicholas A. Bellinger]

Hi majianpeng,

On Wed, 2013-01-30 at 09:19 +0800, majianpeng wrote:
> >On Tue, 2013-01-29 at 15:04 -0800, Andy Grover wrote:
> >> On 01/29/2013 11:03 AM, Nicholas A. Bellinger wrote:
> >> 
> >> > So enabling emulate_write_cache=1 in the case when the underlying device
> >> > has not enabled it is incorrect.
> >> > 
> >> > I'd like to enable this bit when we know the underlying device has WCE=1
> >> > set, but currently there is not a way to determine this (generically)
> >> > from struct block_device.
> >> > 
> >> > So NACK for applying this until there is a method to determine what the
> >> > hardware below is doing.
> >> 
> >> This should be possible from userspace though. I'm planning on looking
> >> up underlying scsi device(s?) using libblkid, and then query the sense
> >> data using libsgutils when adding a block backstore in targetcli.
> >> 
> >
> >Querying the mode pages from userspace would work for the SCSI backstore
> >case, but certainly not for raw block devices.
> >
> >I'd still like to see this exposed to the block layer somehow, so that
> >the setting can be automatically determined by TCM once it's known if
> >the underlying HW has enabled write caching.
> >
> >> It's kind of a hassle, but isn't it a huge performance win if we can
> >> enable this?
> >> 
> >
> >Most certainly, but the danger is reporting WCE=1 (by default in all
> >cases) from TCM to the initiator when the underlying drives do not have
> >caching enabled.  Note that every spinning media device that I've ever
> >seen disables WCE by default from the factory.
>
> Sorry, what's the danger?Can you explain the details?

Current IBLOCK code will always use WRITE_FUA with emulate_write_cache=0
default setting.  It attempts to be safe and invoke write through
schematics with WRITE_FUA when emulate_write_cache=0 is present.

> And for most sata hdd the WCE  is enable by default.

Spinning media SAS drives from the factory still this disable per
default to avoid silent data loss in the event of a hard power failure.

> IMHO, for hard-raid the WCE will be disable, it used the cache of 
> hardraid-card.
> 
> In func sd_revalidate_disk:
> > /*
> >  * We now have all cache related info, determine how we deal
> >  * with flush requests.
> >  */
> > if (sdkp->WCE) {
> > flush |= REQ_FLUSH;
> > if (sdkp->DPOFUA)
> > flush |= REQ_FUA;
> > }
> 
> > blk_queue_flush(sdkp->disk->queue, flush);
> We can use queue->flush_flags.

Good point.

These are request queue hints that IBLOCK could be taking advantage of
here.

> But in func generic_make_request_checks:
> >/*
> >  * Filter flush bio's early so that make_request based
> >  * drivers without flush support don't have to worry
> >  * about them.
> >  */
> > if ((bio->bi_rw & (REQ_FLUSH | REQ_FUA)) && !q->flush_flags) {
> > bio->bi_rw &= ~(REQ_FLUSH | REQ_FUA);
> So if uderlying device don't support WCE, it can remove REQ_FUA|REQ_FLUSH.
> I think enable writecache by default is ok.
> 

Blindly enabling WriteCacheEnabled=1 in all cases for IBLOCK backends to
the SCSI initiator port, and ignoring what the underlying hardware is
doing is not correct either.

So, I've sent out a patch proposing a method for IBLOCK to take
advantage of REQ_FLUSH for WCE=1.  I'm not crazy about the extra pointer
dereferences in the iblock_execute_rw() data I/O path, but it's likely
the most sane way to access to request_queue->flush_flags minus adding a
target callback to update emulate_write_cache in the event of a
blk_queue_flush() call, considering this value may change from below
target/iblock.

(hch, axboe + jejb CC'ed)

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[patch] [SCSI] qla4xxx: don't free NULL dma pool

[Dan Carpenter]

The error path calls dma_pool_free() on this path but "chap_table" is
NULL and "chap_dma" is uninitialized.  It's cleaner to just return
directly.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/scsi/qla4xxx/ql4_mbx.c b/drivers/scsi/qla4xxx/ql4_mbx.c
index 1c57c22..887e409 100644
--- a/drivers/scsi/qla4xxx/ql4_mbx.c
+++ b/drivers/scsi/qla4xxx/ql4_mbx.c
@@ -1404,10 +1404,8 @@ int qla4xxx_get_chap(struct scsi_qla_host *ha, char 
*username, char *password,
dma_addr_t chap_dma;
 
chap_table = dma_pool_alloc(ha->chap_dma_pool, GFP_KERNEL, &chap_dma);
-   if (chap_table == NULL) {
-   ret = -ENOMEM;
-   goto exit_get_chap;
-   }
+   if (chap_table == NULL)
+   return -ENOMEM;
 
chap_size = sizeof(struct ql4_chap_table);
memset(chap_table, 0, chap_size);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch allows IBLOCK to check block hints in request_queue->flush_flags
when reporting current backend device WriteCacheEnabled status to a remote
SCSI initiator port.

This is done via a se_subsystem_api->get_write_cache() call instead of a
backend se_device creation time flag, as we expect REQ_FLUSH bits to possibly
change from an underlying blk_queue_flush() by the SCSI disk driver, or
internal raw struct block_device driver usage.

Also go ahead and update iblock_execute_rw() bio I/O path code to use
REQ_FLUSH + REQ_FUA hints when determining WRITE_FUA usage, and make SPC
emulation code use a spc_check_dev_wce() helper to handle both types of
cases for virtual backend subsystem drivers.

Reported-by: majianpeng 
Cc: majianpeng 
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Cc: James Bottomley 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_device.c  |6 ++
 drivers/target/target_core_iblock.c  |   31 +++
 drivers/target/target_core_spc.c |   21 ++---
 include/target/target_core_backend.h |1 +
 4 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/drivers/target/target_core_device.c 
b/drivers/target/target_core_device.c
index e269510..1d71930 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -772,6 +772,12 @@ int se_dev_set_emulate_write_cache(struct se_device *dev, 
int flag)
pr_err("emulate_write_cache not supported for pSCSI\n");
return -EINVAL;
}
+   if (dev->transport->get_write_cache != NULL) {
+   pr_warn("emulate_write_cache cannot be changed when underlying"
+   " HW reports WriteCacheEnabled, ignoring request\n");
+   return 0;
+   }
+
dev->dev_attrib.emulate_write_cache = flag;
pr_debug("dev[%p]: SE Device WRITE_CACHE_EMULATION flag: %d\n",
dev, dev->dev_attrib.emulate_write_cache);
diff --git a/drivers/target/target_core_iblock.c 
b/drivers/target/target_core_iblock.c
index b526d23..fc45683 100644
--- a/drivers/target/target_core_iblock.c
+++ b/drivers/target/target_core_iblock.c
@@ -154,6 +154,7 @@ static int iblock_configure_device(struct se_device *dev)
 
if (blk_queue_nonrot(q))
dev->dev_attrib.is_nonrot = 1;
+
return 0;
 
 out_free_bioset:
@@ -654,20 +655,24 @@ iblock_execute_rw(struct se_cmd *cmd)
u32 sg_num = sgl_nents;
sector_t block_lba;
unsigned bio_cnt;
-   int rw;
+   int rw = 0;
int i;
 
if (data_direction == DMA_TO_DEVICE) {
+   struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
+   struct request_queue *q = bdev_get_queue(ib_dev->ibd_bd);
/*
-* Force data to disk if we pretend to not have a volatile
-* write cache, or the initiator set the Force Unit Access bit.
+* Force writethrough using WRITE_FUA if a volatile write cache
+* is not enabled, or if initiator set the Force Unit Access 
bit.
 */
-   if (dev->dev_attrib.emulate_write_cache == 0 ||
-   (dev->dev_attrib.emulate_fua_write > 0 &&
-(cmd->se_cmd_flags & SCF_FUA)))
-   rw = WRITE_FUA;
-   else
+   if (q->flush_flags & REQ_FUA) {
+   if (cmd->se_cmd_flags & SCF_FUA)
+   rw = WRITE_FUA;
+   else if (!(q->flush_flags & REQ_FLUSH))
+   rw = WRITE_FUA;
+   } else {
rw = WRITE;
+   }
} else {
rw = READ;
}
@@ -774,6 +779,15 @@ iblock_parse_cdb(struct se_cmd *cmd)
return sbc_parse_cdb(cmd, &iblock_sbc_ops);
 }
 
+bool iblock_get_write_cache(struct se_device *dev)
+{
+   struct iblock_dev *ib_dev = IBLOCK_DEV(dev);
+   struct block_device *bd = ib_dev->ibd_bd;
+   struct request_queue *q = bdev_get_queue(bd);
+
+   return (q->flush_flags & REQ_FLUSH);
+}
+
 static struct se_subsystem_api iblock_template = {
.name   = "iblock",
.inquiry_prod   = "IBLOCK",
@@ -790,6 +804,7 @@ static struct se_subsystem_api iblock_template = {
.show_configfs_dev_params = iblock_show_configfs_dev_params,
.get_device_type= sbc_get_device_type,
.get_blocks = iblock_get_blocks,
+   .get_write_cache= iblock_get_write_cache,
 };
 
 static int __init iblock_module_init(void)
diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 1346f8a..db6d003 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -407,16 +407,31 @@ check_scsi_name:
 }
 EXPORT_SYMBOL(spc_emulate_evpd_83);
 
+static bool
+spc_check_dev_wce(struct se_device *dev)
+{
+

[patch] [SCSI] libosd: check for kzalloc() failure

[Dan Carpenter]

There wasn't any error handling for this kzalloc().

Signed-off-by: Dan Carpenter 

diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
index c06b8e5..d8293f2 100644
--- a/drivers/scsi/osd/osd_initiator.c
+++ b/drivers/scsi/osd/osd_initiator.c
@@ -144,6 +144,10 @@ static int _osd_get_print_system_info(struct osd_dev *od,
odi->osdname_len = get_attrs[a].len;
/* Avoid NULL for memcmp optimization 0-length is good enough */
odi->osdname = kzalloc(odi->osdname_len + 1, GFP_KERNEL);
+   if (!odi->osdname) {
+   ret = -ENOMEM;
+   goto out;
+   }
if (odi->osdname_len)
memcpy(odi->osdname, get_attrs[a].val_ptr, odi->osdname_len);
OSD_INFO("OSD_NAME   [%s]\n", odi->osdname);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: mpt2sas: device_blocked question

[Reddy, Sreekanth]

Hi Spren,

Reason code MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING mean that "A target 
device has stopped responding or is missing but the ReportDeviceMissingDelay 
timer has not expired for this device".

Can you please send me the some more information i.e.

 1. For which operation/TestCase this issue has occurred?
 2. Which Driver & Firmware version you are using?
 3. Can you also please send me the complete log.

Thanks,
Sreekanth.

-Original Message-
From: spren...@gmail.com [mailto:spren...@gmail.com] 
Sent: Saturday, January 26, 2013 9:22 AM
To: JörnEngel; BjørnMork; Nandigama, Nagalakshmi; Reddy, Sreekanth; Support; 
James E.J. Bottomley; DL-MPT Fusion Linux
Cc: linux-scsi@vger.kernel.org
Subject: mpt2sas: device_blocked question

Hi,
  we encounter a problem that a disk is blocked forever, the key log is:

mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0)
mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0)
mpt2sas0: Spinning up disk handle(0x000a), lun(0)
mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0)
mpt2sas0: Spinning up disk handle(0x000a), lun(0)
mpt2sas0: TEST_UNIT_READY: handle(0x000a), lun(0)
mpt2sas0: Spinning up disk handle(0x000a), lun(0) sd 2:0:1:0: 
device_blocked, handle(0x000a)

  looking into the driver code, it seems that the device is blocked by function
_scsih_block_io_to_children_attached_directly() in mpt2sas/mpt2sas_scsih.c with 
reason_code == MPI2_EVENT_SAS_TOPO_RC_DELAY_NOT_RESPONDING,
  what does this reason_code mean please? when should it be returned? and any 
way to handle it?

Best Regards,
spren
2013-01-26

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[scsi:misc 61/65] drivers/scsi/fnic/fnic_scsi.c:441:3: warning: cast from pointer to integer of different size

[kbuild test robot]

tree:   git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc
head:   52cb5cbe9b8ed89db0f8c9eeec8410fcfb0887fd
commit: 6f3b5679f2af1ef3becbf7832d2bce977907c08a [61/65] [SCSI] fnic: fixing 
issues in device and firmware reset code
config: make ARCH=i386 allmodconfig

All warnings:

   drivers/scsi/fnic/fnic_scsi.c:190:39: sparse: context imbalance in 
'__fnic_set_state_flags' - unexpected unlock
   drivers/scsi/fnic/fnic_scsi.c:419:19: sparse: context imbalance in 
'fnic_queuecommand_lck' - unexpected unlock
   drivers/scsi/fnic/fnic_scsi.c:2411:49: sparse: context imbalance in 
'fnic_is_abts_pending' - different lock contexts for basic block
   drivers/scsi/fnic/fnic_scsi.c: In function 'fnic_queuecommand_lck':
>> drivers/scsi/fnic/fnic_scsi.c:441:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:441:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:493:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:493:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:515:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:515:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:515:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
   drivers/scsi/fnic/fnic_scsi.c: In function 'fnic_fcpio_ack_handler':
>> drivers/scsi/fnic/fnic_scsi.c:703:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
   drivers/scsi/fnic/fnic_scsi.c: In function 'fnic_fcpio_icmnd_cmpl_handler':
>> drivers/scsi/fnic/fnic_scsi.c:747:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:747:3: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:904:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:904:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:904:2: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
   drivers/scsi/fnic/fnic_scsi.c: In function 'fnic_fcpio_itmf_cmpl_handler':
>> drivers/scsi/fnic/fnic_scsi.c:1022:5: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1022:5: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1022:5: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1044:4: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1044:4: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1044:4: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_scsi.c:1059:4: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
--
   drivers/scsi/fnic/fnic_trace.c: In function 'fnic_trace_get_buf':
>> drivers/scsi/fnic/fnic_trace.c:80:9: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
   drivers/scsi/fnic/fnic_trace.c: In function 'fnic_get_trace_data':
>> drivers/scsi/fnic/fnic_trace.c:112:10: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
>> drivers/scsi/fnic/fnic_trace.c:149:10: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
   drivers/scsi/fnic/fnic_trace.c: In function 'fnic_trace_buf_init':
>> drivers/scsi/fnic/fnic_trace.c:200:21: warning: cast from pointer to integer 
>> of different size [-Wpointer-to-int-cast]
>> drivers/scsi/fnic/fnic_trace.c:207:2: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
>> drivers/scsi/fnic/fnic_trace.c:215:10: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]
   drivers/scsi/fnic/fnic_trace.c: In function 'fnic_trace_free':
>> drivers/scsi/fnic/fnic_trace.c:260:9: warning: cast to pointer from integer 
>> of different size [-Wint-to-pointer-cast]

sparse warnings: (new ones prefixed by >>)

>> drivers/scsi/fnic/fnic_scsi.c:190:39: sparse: context imbalance in 
>> '__fnic_set_state_flags' - unexpected unlock
   drivers/scsi/fnic/fnic_scsi.c:419:19: sparse: context imbalance in 
'fnic_queuecommand_lck' - unexpected unlock
>> drivers/scsi/fnic/fnic_scsi.c:2411:49: sparse: context imbalance in 
>> 'fnic_is_abts_pending' - different lock c

Re: [scsi:for-next 14/27] drivers/scsi/qla2xxx/qla_os.c:364 qla2x00_free_req_que() info: redundant null check on req->outstanding_cmds calling kfree()

[Saurav Kashyap]

>On Mon, 2012-12-17 at 20:45 +0800, kbuild test robot wrote:
>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
>>for-next
>> head:   e3ff197a750d2912d0bb2a0161c23c18bad250ad
>> commit: 99cc149bbdd78a3f18c6b366e1c239f62d59d096 [14/27] [SCSI]
>>qla2xxx: Determine the number of outstanding commands based on available
>>resources.
>>
>>
>> smatch warnings:
>>
>> + drivers/scsi/qla2xxx/qla_os.c:364 qla2x00_free_req_que() info:
>>redundant null check on req->outstanding_cmds calling kfree()
>>   drivers/scsi/qla2xxx/qla_os.c:686 qla2xxx_queuecommand() error:
>>potential NULL dereference 'rport'.
>
>I flushed all the outstanding qla2xxx patches from the SCSI tree.
>Please fix these issues and resubmit.

Hi James,

We will be re-submitting the patches soon.

Thanks,
~Saurav
>
>Thanks,
>
>James
>
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>




This message and any attached documents contain information from QLogic 
Corporation or its wholly-owned subsidiaries that may be confidential. If you 
are not the intended recipient, you may not read, copy, distribute, or use this 
information. If you have received this transmission in error, please notify the 
sender immediately by reply e-mail and then delete this message.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] fnic: FIP VLAN Discovery Feature Support

[James Bottomley]

On Tue, 2013-01-29 at 16:05 -0800, Hiral Patel wrote:
> FIP VLAN discovery discovers the FCoE VLAN that will be used by all other FIP 
> protocols
> as well as by the FCoE encapsulation for Fibre Channel payloads on the 
> established
> virtual link. One of the goals of FC-BB-5 was to be as nonintrusive as 
> possible on
> initiators and targets, and therefore FIP VLAN discovery occurs in the native 
> VLAN
> used by the initiator or target to exchange Ethernet traffic. The FIP VLAN 
> discovery
> protocol is the only FIP protocol running on the native VLAN; all other FIP 
> protocols
> run on the discovered FCoE VLANs.
> 
> If an administrator has manually configured FCoE VLANs on ENodes and FCFs, 
> there is no need
> to use this protocol. FIP and FCoE will run over the configured VLANs.
> 
> An ENode without FCoE VLANs configuration would use this automated discovery 
> protocol to
> discover over which VLANs FCoE is running.
> 
> The ENode sends a FIP VLAN discovery request to a multicast MAC address 
> called All-FCF-MACs,
> which is a multicast MAC address to which all FCFs listen.
> 
> All FCFs that can be reached in the native VLAN of the ENode are expected to 
> respond on the
> same VLAN with a response that lists one or more FCoE VLANs that are 
> available for the ENode's
> VN_Port login. This protocol has the sole purpose of allowing the ENode to 
> discover all the
> available FCoE VLANs.
> 
> Now the ENode may enable a subset of these VLANs for FCoE Running the FIP 
> protocol in these
> VLANs on a per VLAN basis. And FCoE data transactions also would occur on 
> this VLAN. Hence,
> Except for FIP VLAN discovery, all other FIP and FCoE traffic runs on the 
> selected FCoE VLAN.
> Its only the FIP VLAN Discovery protocol that is permitted to run on the 
> Default native VLAN
> of the system.
> 
> [ NOTE ]
> We are working on moving this feature definitions and functionality to 
> libfcoe module. We need
> this patch to be approved, as Suse is looking forward to merge this feature 
> in SLES 11 SP3 release.
> Once this patch is approved, we will submit patch which should move vlan 
> discovery feature to libfoce.
> 
> Signed-off-by: Anantha Prakash T 
> Signed-off-by: Hiral Patel 

This one isn't applying for me at the top of the scsi-misc tree:

jejb@dabdike> patch -p1 < .git/rebase-apply/patch 
patching file drivers/scsi/fnic/fnic.h
patching file drivers/scsi/fnic/fnic_fcs.c
patching file drivers/scsi/fnic/fnic_fip.h
patching file drivers/scsi/fnic/fnic_main.c
Hunk #3 FAILED at 411.
Hunk #4 succeeded at 628 (offset -1 lines).
Hunk #5 succeeded at 837 (offset -1 lines).
Hunk #6 succeeded at 926 (offset -1 lines).
Hunk #7 succeeded at 988 (offset -1 lines).
1 out of 7 hunks FAILED -- saving rejects to file 
drivers/scsi/fnic/fnic_main.c.rej
patching file drivers/scsi/fnic/vnic_dev.c
patching file drivers/scsi/fnic/vnic_dev.h
patching file drivers/scsi/fnic/vnic_devcmd.h

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH] target: For iblock at default writecache enable.

[majianpeng]

>On Tue, 2013-01-29 at 15:04 -0800, Andy Grover wrote:
>> On 01/29/2013 11:03 AM, Nicholas A. Bellinger wrote:
>> 
>> > So enabling emulate_write_cache=1 in the case when the underlying device
>> > has not enabled it is incorrect.
>> > 
>> > I'd like to enable this bit when we know the underlying device has WCE=1
>> > set, but currently there is not a way to determine this (generically)
>> > from struct block_device.
>> > 
>> > So NACK for applying this until there is a method to determine what the
>> > hardware below is doing.
>> 
>> This should be possible from userspace though. I'm planning on looking
>> up underlying scsi device(s?) using libblkid, and then query the sense
>> data using libsgutils when adding a block backstore in targetcli.
>> 
>
>Querying the mode pages from userspace would work for the SCSI backstore
>case, but certainly not for raw block devices.
>
>I'd still like to see this exposed to the block layer somehow, so that
>the setting can be automatically determined by TCM once it's known if
>the underlying HW has enabled write caching.
>
>> It's kind of a hassle, but isn't it a huge performance win if we can
>> enable this?
>> 
>
>Most certainly, but the danger is reporting WCE=1 (by default in all
>cases) from TCM to the initiator when the underlying drives do not have
>caching enabled.  Note that every spinning media device that I've ever
>seen disables WCE by default from the factory.
Sorry, what's the danger?Can you explain the details?
And for most sata hdd the WCE  is enable by default.
IMHO, for hard-raid the WCE will be disable, it used the cache of hardraid-card.

In func sd_revalidate_disk:
>   /*
>* We now have all cache related info, determine how we deal
>* with flush requests.
>*/
>   if (sdkp->WCE) {
>   flush |= REQ_FLUSH;
>   if (sdkp->DPOFUA)
>   flush |= REQ_FUA;
>   }

>   blk_queue_flush(sdkp->disk->queue, flush);
We can use queue->flush_flags.
But in func generic_make_request_checks:
>/*
>* Filter flush bio's early so that make_request based
>* drivers without flush support don't have to worry
>* about them.
>*/
>   if ((bio->bi_rw & (REQ_FLUSH | REQ_FUA)) && !q->flush_flags) {
>   bio->bi_rw &= ~(REQ_FLUSH | REQ_FUA);
So if uderlying device don't support WCE, it can remove REQ_FUA|REQ_FLUSH.
I think enable writecache by default is ok.

Jianpeng
Thanks!N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{北�"�{ay��,j��f＂�h���z��wア�
⒎�j:+v���w�j�m��赙zZ+�茛j"��!�i

Re: [scsi:for-next 23/27] drivers/scsi/fnic/fnic_scsi.c:1260 fnic_rport_exch_reset() error: we previously assumed 'sc->device' could be null (see line 1237)

[Hiral Patel (hiralpat)]

Hi Dan,

I have fixed the new smatch warnings which was introduced by fnic update
patches and resubmitted new patches.

Thanks,
Hiral

On 12/17/12 5:49 AM, "Dan Carpenter"  wrote:

>[ It doesn't make sense to check for NULL, print an error and then
>  dereference the pointer.  The normal Oops message is easy to debug
>  without the extra code added here.  Or maybe it is possible for
>  the pointer to be NULL in that case we should handle it
>  correctly. ]
>
>Hi Hiral,
>
>FYI, there are new smatch warnings show up in
>
>tree:   git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
>for-next
>head:   e3ff197a750d2912d0bb2a0161c23c18bad250ad
>commit: 188061001ac78b40780af042dd2156e2213e29ed [23/27] [SCSI]
>fnic:fixing issues in device and firmware reset code
>
>  drivers/scsi/fnic/fnic_scsi.c:404 fnic_queuecommand_lck() error:
>potential NULL dereference 'rport'.
>  drivers/scsi/fnic/fnic_scsi.c:303 fnic_queue_wq_copy_desc() error:
>potential NULL dereference 'rport'.
>+ drivers/scsi/fnic/fnic_scsi.c:1260 fnic_rport_exch_reset() error: we
>previously assumed 'sc->device' could be null (see line 1237)
>+ drivers/scsi/fnic/fnic_scsi.c:1325 fnic_terminate_rport_io() error: we
>previously assumed 'sc->device' could be null (see line 1314)
>  drivers/scsi/fnic/fnic_scsi.c:1431 fnic_abort_cmd() error: potential
>NULL dereference 'rport'.
>  drivers/scsi/fnic/fnic_scsi.c:1787 fnic_device_reset() error: potential
>NULL dereference 'rport'.
>
>git remote add scsi
>git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
>git remote update scsi
>git checkout 188061001ac78b40780af042dd2156e2213e29ed
>vim +1260 drivers/scsi/fnic/fnic_scsi.c
>
>18806100 Hiral Patel   2012-12-10  1231if (io_req->abts_done) {
>18806100 Hiral Patel   2012-12-10  1232
>shost_printk(KERN_ERR,
>fnic->lport->host,
>18806100 Hiral Patel   2012-12-10  1233
>"fnic_rport_exch_reset:
>io_req->abts_done is set "
>18806100 Hiral Patel   2012-12-10  1234"state is %s\n",
>18806100 Hiral Patel   2012-12-10  1235
>   fnic_ioreq_state_to_str(CMD_STATE(sc)));
>18806100 Hiral Patel   2012-12-10  1236}
>18806100 Hiral Patel   2012-12-10 @1237if (sc->device == NULL)
>18806100 Hiral Patel   2012-12-10  1238
>shost_printk(KERN_ERR,
>fnic->lport->host,
>18806100 Hiral Patel   2012-12-10  1239
>"fnic_rport_exch_reset:
>sc->device is null state is "
>18806100 Hiral Patel   2012-12-10  1240"%s\n",
>fnic_ioreq_state_to_str(CMD_STATE(sc)));
>18806100 Hiral Patel   2012-12-10  1241
>5df6d737 Abhijeet Joglekar 2009-04-17  1242old_ioreq_state =
>CMD_STATE(sc);
>5df6d737 Abhijeet Joglekar 2009-04-17  1243CMD_STATE(sc) =
>FNIC_IOREQ_ABTS_PENDING;
>5df6d737 Abhijeet Joglekar 2009-04-17  1244CMD_ABTS_STATUS(sc) =
>FCPIO_INVALID_CODE;
>18806100 Hiral Patel   2012-12-10  1245if (CMD_FLAGS(sc) &
>FNIC_DEVICE_RESET) {
>18806100 Hiral Patel   2012-12-10  1246abt_tag = (tag |
>FNIC_TAG_DEV_RST);
>18806100 Hiral Patel   2012-12-10  1247
>FNIC_SCSI_DBG(KERN_DEBUG,
>fnic->lport->host,
>18806100 Hiral Patel   2012-12-10  1248
>"fnic_rport_exch_reset
>dev rst sc 0x%p\n",
>18806100 Hiral Patel   2012-12-10  1249sc);
>18806100 Hiral Patel   2012-12-10  1250}
>5df6d737 Abhijeet Joglekar 2009-04-17  1251
>5df6d737 Abhijeet Joglekar 2009-04-17  1252
>BUG_ON(io_req->abts_done);
>5df6d737 Abhijeet Joglekar 2009-04-17  1253
>5df6d737 Abhijeet Joglekar 2009-04-17  1254
>FNIC_SCSI_DBG(KERN_DEBUG,
>fnic->lport->host,
>5df6d737 Abhijeet Joglekar 2009-04-17  1255
>"fnic_rport_reset_exch: Issuing abts\n");
>5df6d737 Abhijeet Joglekar 2009-04-17  1256
>5df6d737 Abhijeet Joglekar 2009-04-17  1257
>   spin_unlock_irqrestore(io_lock, flags);
>5df6d737 Abhijeet Joglekar 2009-04-17  1258
>5df6d737 Abhijeet Joglekar 2009-04-17  1259/* Now queue the abort
>command to firmware */
>5df6d737 Abhijeet Joglekar 2009-04-17 @1260
>   int_to_scsilun(sc->device->lun, &fc_lun);
>5df6d737 Abhijeet Joglekar 2009-04-17  1261
>18806100 Hiral Patel   2012-12-10  1262if
>(fnic_queue_abort_io_req(fnic, abt_tag,
>5df6d737 Abhijeet Joglekar 2009-04-17  1263
>FCPIO_ITMF_ABT_TASK_TERM,
>5df6d737 Abhijeet Joglekar 2009-04-17  1264
>fc_lun.scsi_lun,
>io_req)) {
>5df6d737 Abhijeet Joglekar 2009-04-17  1265/*
>5df6d737 Abhijeet Joglekar 2009-04-17  1266 * Revert the 
>cmd state
>back to old state, if
>25985edc Lucas De Marchi   2011-03-30  1267 * it hasn't 
>changed in
>between. This cmd will get
>5df6d737 Abhijeet Jog

[PATCH 07/10] fnic: Fnic Trace Utility

[Hiral Patel]

Fnic Trace utility is a tracing functionality built directly into fnic driver
to trace events. The benefit that trace buffer brings to fnic driver is the
ability to see what it happening inside the fnic driver. It also provides the
capability to trace every IO event inside fnic driver to debug panics, hangs
and potentially IO corruption issues. This feature makes it easy to find
problems in fnic driver and it also helps in tracking down strange bugs in a
more manageable way. Trace buffer is shared across all fnic instances for
this implementation.

Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/Makefile   |2 +
 drivers/scsi/fnic/fnic.h |1 +
 drivers/scsi/fnic/fnic_debugfs.c |  312 ++
 drivers/scsi/fnic/fnic_main.c|   14 ++
 drivers/scsi/fnic/fnic_scsi.c|  120 +--
 drivers/scsi/fnic/fnic_trace.c   |  264 
 drivers/scsi/fnic/fnic_trace.h   |   80 ++
 7 files changed, 782 insertions(+), 11 deletions(-)
 create mode 100644 drivers/scsi/fnic/fnic_debugfs.c
 create mode 100644 drivers/scsi/fnic/fnic_trace.c
 create mode 100644 drivers/scsi/fnic/fnic_trace.h

diff --git a/drivers/scsi/fnic/Makefile b/drivers/scsi/fnic/Makefile
index 37c3440..383598f 100644
--- a/drivers/scsi/fnic/Makefile
+++ b/drivers/scsi/fnic/Makefile
@@ -7,6 +7,8 @@ fnic-y  := \
fnic_res.o \
fnic_fcs.o \
fnic_scsi.o \
+   fnic_trace.o \
+   fnic_debugfs.o \
vnic_cq.o \
vnic_dev.o \
vnic_intr.o \
diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 9c95a1a..98436c3 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -26,6 +26,7 @@
 #include 
 #include "fnic_io.h"
 #include "fnic_res.h"
+#include "fnic_trace.h"
 #include "vnic_dev.h"
 #include "vnic_wq.h"
 #include "vnic_rq.h"
diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c
new file mode 100644
index 000..bc06f9b
--- /dev/null
+++ b/drivers/scsi/fnic/fnic_debugfs.c
@@ -0,0 +1,312 @@
+/*
+ * Copyright 2012 Cisco Systems, Inc.  All rights reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include "fnic.h"
+
+static struct dentry *fnic_trace_debugfs_root;
+static struct dentry *fnic_trace_debugfs_file;
+static struct dentry *fnic_trace_enable;
+
+/*
+ * fnic_trace_ctrl_open - Open the trace_enable file
+ * @inode: The inode pointer.
+ * @file: The file pointer to attach the trace enable/disable flag.
+ *
+ * Description:
+ * This routine opens a debugsfs file trace_enable.
+ *
+ * Returns:
+ * This function returns zero if successful.
+ */
+static int fnic_trace_ctrl_open(struct inode *inode, struct file *filp)
+{
+   filp->private_data = inode->i_private;
+   return 0;
+}
+
+/*
+ * fnic_trace_ctrl_read - Read a trace_enable debugfs file
+ * @filp: The file pointer to read from.
+ * @ubuf: The buffer to copy the data to.
+ * @cnt: The number of bytes to read.
+ * @ppos: The position in the file to start reading from.
+ *
+ * Description:
+ * This routine reads value of variable fnic_tracing_enabled
+ * and stores into local @buf. It will start reading file at @ppos and
+ * copy up to @cnt of data to @ubuf from @buf.
+ *
+ * Returns:
+ * This function returns the amount of data that was read.
+ */
+static ssize_t fnic_trace_ctrl_read(struct file *filp,
+ char __user *ubuf,
+ size_t cnt, loff_t *ppos)
+{
+   char buf[64];
+   int len;
+   len = sprintf(buf, "%u\n", fnic_tracing_enabled);
+
+   return simple_read_from_buffer(ubuf, cnt, ppos, buf, len);
+}
+
+/*
+ * fnic_trace_ctrl_write - Write to trace_enable debugfs file
+ * @filp: The file pointer to write from.
+ * @ubuf: The buffer to copy the data from.
+ * @cnt: The number of bytes to write.
+ * @ppos: The position in the file to start writing to.
+ *
+ * Description:
+ * This routine writes data from user buffer @ubuf to buffer @buf and
+ * sets fnic_tracing_enabled value as per user input.
+ *
+ * Returns:
+ * This function returns the amount of data that was written.
+ */
+static ssize_t fnic_trace_ctrl_write(struct file *filp,
+ const char __user *ubuf,
+   

[PATCH 05/10] fnic: fnic driver may hit BUG_ON on device reset

[Hiral Patel]

The issue was observed when LUN Reset is issued through IOCTL or sg_reset
utility.

fnic driver issues LUN RESET to firmware. On successful completion of device
reset, driver cleans up all the pending IOs that were issued prior to device
reset. These pending IOs are expected to be in ABTS_PENDING state. This works
fine, when the device reset operation resulted from midlayer, but not when
device reset was triggered from IOCTL path as the pending IOs were not in
ABTS_PENDING state. execution path hits panic if the pending IO is not in
ABTS_PENDING state.

Changes:
The fix replaces BUG_ON check in fnic_clean_pending_aborts() with marking
pending IOs as ABTS_PENDING if they were not in ABTS_PENDING state and skips
if they were already in ABTS_PENDING state. An extra check is added to validate
the abort status of the commands after a delay of 2 * E_D_TOV using a
helper function. The helper function returns 1 if it finds any pending IO in
ABTS_PENDING state, belong to the LUN on which device reset was issued else 0.
With this, device reset operation returns success only if the helper funciton
returns 0, otherwise it returns failure.

Other changes:
- Removed code in fnic_clean_pending_aborts() that returns failure if it finds
  io_req NULL, instead of returning failure added code to continue with next io
- Added device reset flags for debugging in fnic_terminate_rport_io,
  fnic_rport_exch_reset, and fnic_clean_pending_aborts

Signed-off-by: Narsimhulu Musini 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic.h  |2 +
 drivers/scsi/fnic/fnic_scsi.c |  121 ++---
 2 files changed, 116 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 63b35c8..b8e6644 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -303,6 +303,8 @@ const char *fnic_state_to_str(unsigned int state);
 void fnic_log_q_error(struct fnic *fnic);
 void fnic_handle_link_event(struct fnic *fnic);
 
+int fnic_is_abts_pending(struct fnic *, struct scsi_cmnd *);
+
 static inline int
 fnic_chk_state_flags_locked(struct fnic *fnic, unsigned long st_flags)
 {
diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
index 2f46509..6483081 100644
--- a/drivers/scsi/fnic/fnic_scsi.c
+++ b/drivers/scsi/fnic/fnic_scsi.c
@@ -1271,7 +1271,8 @@ static void fnic_rport_exch_reset(struct fnic *fnic, u32 
port_id)
spin_unlock_irqrestore(io_lock, flags);
} else {
spin_lock_irqsave(io_lock, flags);
-   CMD_FLAGS(sc) |= FNIC_DEV_RST_TERM_ISSUED;
+   if (CMD_FLAGS(sc) & FNIC_DEVICE_RESET)
+   CMD_FLAGS(sc) |= FNIC_DEV_RST_TERM_ISSUED;
spin_unlock_irqrestore(io_lock, flags);
}
}
@@ -1379,7 +1380,8 @@ void fnic_terminate_rport_io(struct fc_rport *rport)
spin_unlock_irqrestore(io_lock, flags);
} else {
spin_lock_irqsave(io_lock, flags);
-   CMD_FLAGS(sc) |= FNIC_DEV_RST_TERM_ISSUED;
+   if (CMD_FLAGS(sc) & FNIC_DEVICE_RESET)
+   CMD_FLAGS(sc) |= FNIC_DEV_RST_TERM_ISSUED;
spin_unlock_irqrestore(io_lock, flags);
}
}
@@ -1592,7 +1594,7 @@ lr_io_req_end:
 static int fnic_clean_pending_aborts(struct fnic *fnic,
 struct scsi_cmnd *lr_sc)
 {
-   int tag;
+   int tag, abt_tag;
struct fnic_io_req *io_req;
spinlock_t *io_lock;
unsigned long flags;
@@ -1601,6 +1603,7 @@ static int fnic_clean_pending_aborts(struct fnic *fnic,
struct scsi_lun fc_lun;
struct scsi_device *lun_dev = lr_sc->device;
DECLARE_COMPLETION_ONSTACK(tm_done);
+   enum fnic_ioreq_state old_ioreq_state;
 
for (tag = 0; tag < FNIC_MAX_IO_REQ; tag++) {
sc = scsi_host_find_tag(fnic->lport->host, tag);
@@ -1629,7 +1632,41 @@ static int fnic_clean_pending_aborts(struct fnic *fnic,
  "Found IO in %s on lun\n",
  fnic_ioreq_state_to_str(CMD_STATE(sc)));
 
-   BUG_ON(CMD_STATE(sc) != FNIC_IOREQ_ABTS_PENDING);
+   if (CMD_STATE(sc) == FNIC_IOREQ_ABTS_PENDING) {
+   spin_unlock_irqrestore(io_lock, flags);
+   continue;
+   }
+   if ((CMD_FLAGS(sc) & FNIC_DEVICE_RESET) &&
+   (!(CMD_FLAGS(sc) & FNIC_DEV_RST_PENDING))) {
+   FNIC_SCSI_DBG(KERN_INFO, fnic->lport->host,
+   "%s dev rst not pending sc 0x%p\n", __func__,
+   sc);
+   spin_unlock_irqrestore(io_lock, flags);
+   continue;
+   }
+   old_ioreq_state = CMD_STATE(sc);
+

[PATCH 09/10] fnic: Kernel panic due to FIP mode misconfiguration

[Hiral Patel]

If switch configured in FIP and adapter configured in non-fip mode, driver
panics while queueing FIP frame in non-existing fip_frame_queue. Added config
check before queueing FIP frame in misconfiguration case to avoid kernel panic.

Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic_fcs.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/fnic/fnic_fcs.c b/drivers/scsi/fnic/fnic_fcs.c
index d8aceb0..b9950f1 100644
--- a/drivers/scsi/fnic/fnic_fcs.c
+++ b/drivers/scsi/fnic/fnic_fcs.c
@@ -602,6 +602,12 @@ static inline int fnic_import_rq_eth_pkt(struct fnic 
*fnic, struct sk_buff *skb)
skb_reset_mac_header(skb);
}
if (eh->h_proto == htons(ETH_P_FIP)) {
+   if (!(fnic->config.flags & VFCF_FIP_CAPABLE)) {
+   printk(KERN_ERR "Dropped FIP frame, as firmware "
+   "uses non-FIP mode, Enable FIP "
+   "using UCSM\n");
+   goto drop;
+   }
skb_queue_tail(&fnic->fip_frame_queue, skb);
queue_work(fnic_fip_queue, &fnic->fip_frame_work);
return 1;   /* let caller know packet was used */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/10] fnic:fixing issues in device and firmware reset code

[Hiral Patel]

1. Handling overlapped firmware resets
 This fix serialize multiple firmware resets to avoid situation where fnic
 device fails to come up for link up event, when firmware resets are issued
 back to back. If there are overlapped firmware resets are issued,
 the firmware reset operation checks whether there is any firmware reset in
 progress, if so it polls for its completion in a loop with 100ms delay.

2. Handling device reset timeout
 fnic_device_reset code has been modified to handle Device reset timeout:
 - Issue terminate on device reset timeout.
 - Introduced flags field (one of the scratch fields in scsi_cmnd).
 With this, device reset request would have DEVICE_RESET flag set for other
 routines to determine the type of the request.
 Also modified fnic_terminate_rport_io, fnic_rport_exch_rset, completion
 routines to handle SCSI commands with DEVICE_RESET flag.

3. LUN/Device Reset hangs when issued through IOCTL using utilities like
   sg_reset.
 Each SCSI command is associated with a valid tag, fnic uses this tag to
 retrieve associated scsi command on completion. the LUN/Device Reset issued
 through IOCTL resulting into a SCSI command that is not associated with a
 valid tag. So fnic fails to retrieve associated scsi command on completion,
 which causes hang. This fix allocates tag, associates it with the
 scsi command and frees the tag, when the operation completed.

4. Preventing IOs during firmware reset.
 Current fnic implementation allows IO submissions during firmware reset.
 This fix synchronizes IO submissions and firmware reset operations.
 It ensures that IOs issued to fnic prior to reset will be issued to the
 firmware before firmware reset.

Signed-off-by: Narsimhulu Musini 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic.h  |   42 +
 drivers/scsi/fnic/fnic_main.c |3 +
 drivers/scsi/fnic/fnic_scsi.c |  384 +
 3 files changed, 397 insertions(+), 32 deletions(-)

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 95a5ba2..63b35c8 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -56,6 +56,19 @@
 #define FNIC_NO_TAG -1
 
 /*
+ * Command flags to identify the type of command and for other future
+ * use.
+ */
+#define FNIC_NO_FLAGS  0
+#define FNIC_CDB_REQ   BIT(1)  /* All IOs with a valid CDB */
+#define FNIC_BLOCKING_REQ  BIT(2)  /* All blocking Requests */
+#define FNIC_DEVICE_RESET  BIT(3)  /* Device reset request */
+#define FNIC_DEV_RST_PENDING   BIT(4)  /* Device reset pending */
+#define FNIC_DEV_RST_TIMED_OUT BIT(5)  /* Device reset timed out */
+#define FNIC_DEV_RST_TERM_ISSUED   BIT(6)  /* Device reset terminate */
+#define FNIC_DEV_RST_DONE  BIT(7)  /* Device reset done */
+
+/*
  * Usage of the scsi_cmnd scratchpad.
  * These fields are locked by the hashed io_req_lock.
  */
@@ -64,6 +77,7 @@
 #define CMD_ABTS_STATUS(Cmnd)  ((Cmnd)->SCp.Message)
 #define CMD_LR_STATUS(Cmnd)((Cmnd)->SCp.have_data_in)
 #define CMD_TAG(Cmnd)   ((Cmnd)->SCp.sent_command)
+#define CMD_FLAGS(Cmnd) ((Cmnd)->SCp.Status)
 
 #define FCPIO_INVALID_CODE 0x100 /* hdr_status value unused by firmware */
 
@@ -71,9 +85,28 @@
 #define FNIC_HOST_RESET_TIMEOUT 1  /* mSec */
 #define FNIC_RMDEVICE_TIMEOUT1000   /* mSec */
 #define FNIC_HOST_RESET_SETTLE_TIME  30 /* Sec */
+#define FNIC_ABT_TERM_DELAY_TIMEOUT  500/* mSec */
 
 #define FNIC_MAX_FCP_TARGET 256
 
+/**
+ * state_flags to identify host state along along with fnic's state
+ **/
+#define __FNIC_FLAGS_FWRESET   BIT(0) /* fwreset in progress */
+#define __FNIC_FLAGS_BLOCK_IO  BIT(1) /* IOs are blocked */
+
+#define FNIC_FLAGS_NONE(0)
+#define FNIC_FLAGS_FWRESET (__FNIC_FLAGS_FWRESET | \
+   __FNIC_FLAGS_BLOCK_IO)
+
+#define FNIC_FLAGS_IO_BLOCKED  (__FNIC_FLAGS_BLOCK_IO)
+
+#define fnic_set_state_flags(fnicp, st_flags)  \
+   __fnic_set_state_flags(fnicp, st_flags, 0)
+
+#define fnic_clear_state_flags(fnicp, st_flags)  \
+   __fnic_set_state_flags(fnicp, st_flags, 1)
+
 extern unsigned int fnic_log_level;
 
 #define FNIC_MAIN_LOGGING 0x01
@@ -170,6 +203,9 @@ struct fnic {
 
struct completion *remove_wait; /* device remove thread blocks */
 
+   atomic_t in_flight; /* io counter */
+   u32 _reserved;  /* fill hole */
+   unsigned long state_flags;  /* protected by host lock */
enum fnic_state state;
spinlock_t fnic_lock;
 
@@ -267,4 +303,10 @@ const char *fnic_state_to_str(unsigned int state);
 void fnic_log_q_error(struct fnic *fnic);
 void fnic_handle_link_event(struct fnic *fnic);
 
+static inline int
+fnic_chk_state_flags_locked(

[PATCH 04/10] fnic: Fix SGEs limit

[Hiral Patel]

Driver allows IOs with more SGEs than max SGEs supported by Palo. The current 
max SGEs
supported by the fnic driver is 1024. The current register settings on Palo 
supports
a max of 256 only. Palo would return any IO with more than 256 SGEs with an 
error
indicating INVALID_SGLS. Fnic driver should limit the max supported SGLs in
the driver to 256 to avoid this error.

Signed-off-by: Sesidhar Baddela 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic_io.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/fnic/fnic_io.h b/drivers/scsi/fnic/fnic_io.h
index f0b8969..3455c34 100644
--- a/drivers/scsi/fnic/fnic_io.h
+++ b/drivers/scsi/fnic/fnic_io.h
@@ -21,7 +21,7 @@
 #include 
 
 #define FNIC_DFLT_SG_DESC_CNT  32
-#define FNIC_MAX_SG_DESC_CNT1024/* Maximum descriptors per sgl */
+#define FNIC_MAX_SG_DESC_CNT256 /* Maximum descriptors per sgl */
 #define FNIC_SG_DESC_ALIGN  16  /* Descriptor address alignment */
 
 struct host_sg_desc {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/10] fnic: New debug flags and debug log messages

[Hiral Patel]

Added new fnic debug flags for identifying IO state at every stage of IO while 
debugging
and also added more log messages for better debugging capability.

Signed-off-by: Sesidhar Baddela 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic.h  |   31 ---
 drivers/scsi/fnic/fnic_io.h   |4 +-
 drivers/scsi/fnic/fnic_scsi.c |  121 +
 3 files changed, 135 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index b8e6644..9c95a1a 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -59,14 +59,29 @@
  * Command flags to identify the type of command and for other future
  * use.
  */
-#define FNIC_NO_FLAGS  0
-#define FNIC_CDB_REQ   BIT(1)  /* All IOs with a valid CDB */
-#define FNIC_BLOCKING_REQ  BIT(2)  /* All blocking Requests */
-#define FNIC_DEVICE_RESET  BIT(3)  /* Device reset request */
-#define FNIC_DEV_RST_PENDING   BIT(4)  /* Device reset pending */
-#define FNIC_DEV_RST_TIMED_OUT BIT(5)  /* Device reset timed out */
-#define FNIC_DEV_RST_TERM_ISSUED   BIT(6)  /* Device reset terminate */
-#define FNIC_DEV_RST_DONE  BIT(7)  /* Device reset done */
+#define FNIC_NO_FLAGS   0
+#define FNIC_IO_INITIALIZED BIT(0)
+#define FNIC_IO_ISSUED  BIT(1)
+#define FNIC_IO_DONEBIT(2)
+#define FNIC_IO_REQ_NULLBIT(3)
+#define FNIC_IO_ABTS_PENDINGBIT(4)
+#define FNIC_IO_ABORTED BIT(5)
+#define FNIC_IO_ABTS_ISSUED BIT(6)
+#define FNIC_IO_TERM_ISSUED BIT(7)
+#define FNIC_IO_INTERNAL_TERM_ISSUEDBIT(8)
+#define FNIC_IO_ABT_TERM_DONE   BIT(9)
+#define FNIC_IO_ABT_TERM_REQ_NULL   BIT(10)
+#define FNIC_IO_ABT_TERM_TIMED_OUT  BIT(11)
+#define FNIC_DEVICE_RESET   BIT(12)  /* Device reset request */
+#define FNIC_DEV_RST_ISSUED BIT(13)
+#define FNIC_DEV_RST_TIMED_OUT  BIT(14)
+#define FNIC_DEV_RST_ABTS_ISSUEDBIT(15)
+#define FNIC_DEV_RST_TERM_ISSUEDBIT(16)
+#define FNIC_DEV_RST_DONE   BIT(17)
+#define FNIC_DEV_RST_REQ_NULL   BIT(18)
+#define FNIC_DEV_RST_ABTS_DONE  BIT(19)
+#define FNIC_DEV_RST_TERM_DONE  BIT(20)
+#define FNIC_DEV_RST_ABTS_PENDING   BIT(21)
 
 /*
  * Usage of the scsi_cmnd scratchpad.
diff --git a/drivers/scsi/fnic/fnic_io.h b/drivers/scsi/fnic/fnic_io.h
index 3455c34..c35b8f1 100644
--- a/drivers/scsi/fnic/fnic_io.h
+++ b/drivers/scsi/fnic/fnic_io.h
@@ -45,7 +45,8 @@ enum fnic_sgl_list_type {
 };
 
 enum fnic_ioreq_state {
-   FNIC_IOREQ_CMD_PENDING = 0,
+   FNIC_IOREQ_NOT_INITED = 0,
+   FNIC_IOREQ_CMD_PENDING,
FNIC_IOREQ_ABTS_PENDING,
FNIC_IOREQ_ABTS_COMPLETE,
FNIC_IOREQ_CMD_COMPLETE,
@@ -60,6 +61,7 @@ struct fnic_io_req {
u8 sgl_type; /* device DMA descriptor list type */
u8 io_completed:1; /* set to 1 when fw completes IO */
u32 port_id; /* remote port DID */
+   unsigned long start_time; /* in jiffies */
struct completion *abts_done; /* completion for abts */
struct completion *dr_done; /* completion for device reset */
 };
diff --git a/drivers/scsi/fnic/fnic_scsi.c b/drivers/scsi/fnic/fnic_scsi.c
index 6483081..661efa4 100644
--- a/drivers/scsi/fnic/fnic_scsi.c
+++ b/drivers/scsi/fnic/fnic_scsi.c
@@ -47,6 +47,7 @@ const char *fnic_state_str[] = {
 };
 
 static const char *fnic_ioreq_state_str[] = {
+   [FNIC_IOREQ_NOT_INITED] = "FNIC_IOREQ_NOT_INITED",
[FNIC_IOREQ_CMD_PENDING] = "FNIC_IOREQ_CMD_PENDING",
[FNIC_IOREQ_ABTS_PENDING] = "FNIC_IOREQ_ABTS_PENDING",
[FNIC_IOREQ_ABTS_COMPLETE] = "FNIC_IOREQ_ABTS_COMPLETE",
@@ -349,6 +350,8 @@ static inline int fnic_queue_wq_copy_desc(struct fnic *fnic,
 
if (unlikely(!vnic_wq_copy_desc_avail(wq))) {
spin_unlock_irqrestore(&fnic->wq_copy_lock[0], intr_flags);
+   FNIC_SCSI_DBG(KERN_INFO, fnic->lport->host,
+ "fnic_queue_wq_copy_desc failure - no descriptors\n");
return SCSI_MLQUEUE_HOST_BUSY;
}
 
@@ -420,7 +423,8 @@ static int fnic_queuecommand_lck(struct scsi_cmnd *sc, void 
(*done)(struct scsi_
 * caller disabling them.
 */
spin_unlock(lp->host->host_lock);
-   CMD_FLAGS(sc) = FNIC_CDB_REQ;
+   CMD_STATE(sc) = FNIC_IOREQ_NOT_INITED;
+   CMD_FLAGS(sc) = FNIC_NO_FLAGS;
 
/* Get a new io_req for this SCSI IO */
io_req = mempool_alloc(fnic->io_req_pool, GFP_ATOMIC);
@@ -467,8 +471,10 @@ static int fnic_queuecommand_lck(struct scsi_cmnd *sc, 
void (*done)(struct scsi_
 
/* initialize rest of io_req */
io_req->port_id = rport->port_id;
+   io_req->start_time = jiffies;
CMD_STATE(sc) = FNIC_IOREQ_CMD_PENDING;
CMD_SP(sc) = (char *)io_req;
+   CMD_FL

[PATCH 08/10] fnic: FIP VLAN Discovery Feature Support

[Hiral Patel]

FIP VLAN discovery discovers the FCoE VLAN that will be used by all other FIP 
protocols
as well as by the FCoE encapsulation for Fibre Channel payloads on the 
established
virtual link. One of the goals of FC-BB-5 was to be as nonintrusive as possible 
on
initiators and targets, and therefore FIP VLAN discovery occurs in the native 
VLAN
used by the initiator or target to exchange Ethernet traffic. The FIP VLAN 
discovery
protocol is the only FIP protocol running on the native VLAN; all other FIP 
protocols
run on the discovered FCoE VLANs.

If an administrator has manually configured FCoE VLANs on ENodes and FCFs, 
there is no need
to use this protocol. FIP and FCoE will run over the configured VLANs.

An ENode without FCoE VLANs configuration would use this automated discovery 
protocol to
discover over which VLANs FCoE is running.

The ENode sends a FIP VLAN discovery request to a multicast MAC address called 
All-FCF-MACs,
which is a multicast MAC address to which all FCFs listen.

All FCFs that can be reached in the native VLAN of the ENode are expected to 
respond on the
same VLAN with a response that lists one or more FCoE VLANs that are available 
for the ENode's
VN_Port login. This protocol has the sole purpose of allowing the ENode to 
discover all the
available FCoE VLANs.

Now the ENode may enable a subset of these VLANs for FCoE Running the FIP 
protocol in these
VLANs on a per VLAN basis. And FCoE data transactions also would occur on this 
VLAN. Hence,
Except for FIP VLAN discovery, all other FIP and FCoE traffic runs on the 
selected FCoE VLAN.
Its only the FIP VLAN Discovery protocol that is permitted to run on the 
Default native VLAN
of the system.

[ NOTE ]
We are working on moving this feature definitions and functionality to libfcoe 
module. We need
this patch to be approved, as Suse is looking forward to merge this feature in 
SLES 11 SP3 release.
Once this patch is approved, we will submit patch which should move vlan 
discovery feature to libfoce.

Signed-off-by: Anantha Prakash T 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic.h|   32 +++
 drivers/scsi/fnic/fnic_fcs.c|  557 ++-
 drivers/scsi/fnic/fnic_fip.h|   68 +
 drivers/scsi/fnic/fnic_main.c   |   51 +++-
 drivers/scsi/fnic/vnic_dev.c|   10 +
 drivers/scsi/fnic/vnic_dev.h|2 +
 drivers/scsi/fnic/vnic_devcmd.h |   67 +
 7 files changed, 783 insertions(+), 4 deletions(-)
 create mode 100644 drivers/scsi/fnic/fnic_fip.h

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 98436c3..acec42a 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -192,6 +192,18 @@ enum fnic_state {
 
 struct mempool;
 
+enum fnic_evt {
+   FNIC_EVT_START_VLAN_DISC = 1,
+   FNIC_EVT_START_FCF_DISC = 2,
+   FNIC_EVT_MAX,
+};
+
+struct fnic_event {
+   struct list_head list;
+   struct fnic *fnic;
+   enum fnic_evt event;
+};
+
 /* Per-instance private data structure */
 struct fnic {
struct fc_lport *lport;
@@ -254,6 +266,18 @@ struct fnic {
struct sk_buff_head frame_queue;
struct sk_buff_head tx_queue;
 
+   /*** FIP related data members  -- start ***/
+   void (*set_vlan)(struct fnic *, u16 vlan);
+   struct work_struct  fip_frame_work;
+   struct sk_buff_head fip_frame_queue;
+   struct timer_list   fip_timer;
+   struct list_headvlans;
+   spinlock_t  vlans_lock;
+
+   struct work_struct  event_work;
+   struct list_headevlist;
+   /*** FIP related data members  -- end ***/
+
/* copy work queue cache line section */
cacheline_aligned struct vnic_wq_copy wq_copy[FNIC_WQ_COPY_MAX];
/* completion queue cache line section */
@@ -278,6 +302,7 @@ static inline struct fnic *fnic_from_ctlr(struct fcoe_ctlr 
*fip)
 }
 
 extern struct workqueue_struct *fnic_event_queue;
+extern struct workqueue_struct *fnic_fip_queue;
 extern struct device_attribute *fnic_attrs[];
 
 void fnic_clear_intr_mode(struct fnic *fnic);
@@ -289,6 +314,7 @@ int fnic_send(struct fc_lport *, struct fc_frame *);
 void fnic_free_wq_buf(struct vnic_wq *wq, struct vnic_wq_buf *buf);
 void fnic_handle_frame(struct work_struct *work);
 void fnic_handle_link(struct work_struct *work);
+void fnic_handle_event(struct work_struct *work);
 int fnic_rq_cmpl_handler(struct fnic *fnic, int);
 int fnic_alloc_rq_frame(struct vnic_rq *rq);
 void fnic_free_rq_buf(struct vnic_rq *rq, struct vnic_rq_buf *buf);
@@ -321,6 +347,12 @@ void fnic_handle_link_event(struct fnic *fnic);
 
 int fnic_is_abts_pending(struct fnic *, struct scsi_cmnd *);
 
+void fnic_handle_fip_frame(struct work_struct *work);
+void fnic_handle_fip_event(struct fnic *fnic);
+void fnic_fcoe_reset_vlans(struct fnic *fnic);
+void fnic_fcoe_evlist_free(struct fnic *fnic);
+extern void fnic_handle_fip_timer(struct fnic *fnic);
+
 static inline int
 fnic_chk_sta

[PATCH 10/10] fnic: Incremented driver version

[Hiral Patel]

Incrementing driver versio after bug fixes and new feature commits.

Signed-off-by: Brian Uchino 
Signed-off-by: Hiral Patel 
---
 drivers/scsi/fnic/fnic.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index acec42a..b6d1f92 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -38,7 +38,7 @@
 
 #define DRV_NAME   "fnic"
 #define DRV_DESCRIPTION"Cisco FCoE HBA Driver"
-#define DRV_VERSION"1.5.0.2"
+#define DRV_VERSION"1.5.0.22"
 #define PFXDRV_NAME ": "
 #define DFX DRV_NAME "%d: "
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

linux-scsi@vger.kernel.org

[Hiral Patel (hiralpat)]

Hi James,

Sorry, somehow I missed looking at kbuild emails. I have fixed sparse and
smatch issues and resubmitted patches 3-10.

Thanks,
Hiral

On 1/28/13 7:16 PM, "James Bottomley"
 wrote:

>On Mon, 2012-12-17 at 21:50 +0800, kbuild test robot wrote:
>> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git
>>for-next
>> head:   e3ff197a750d2912d0bb2a0161c23c18bad250ad
>> commit: 188061001ac78b40780af042dd2156e2213e29ed [23/27] [SCSI]
>>fnic:fixing issues in device and firmware reset code
>> 
>> 
>> sparse warnings:
>> 
>> + drivers/scsi/fnic/fnic_scsi.c:183:35: sparse: invalid assignment: &=
>> drivers/scsi/fnic/fnic_scsi.c:183:35:left side has type restricted
>>unsigned long long
>> drivers/scsi/fnic/fnic_scsi.c:183:35:right side has type unsigned
>>long long
>> drivers/scsi/fnic/fnic_scsi.c:185:35: sparse: invalid assignment: |=
>> drivers/scsi/fnic/fnic_scsi.c:185:35:left side has type restricted
>>unsigned long long
>> drivers/scsi/fnic/fnic_scsi.c:185:35:right side has type unsigned
>>long long
>
>I still haven't seen fixes for these patches.  I've flushed the fnic
>patches from the tree pending resolution.  That means the only remaining
>fnic patches I have are
>
>1/10 fnic: updated MAINTAINERS list
>2/10 fnic: fix for trusted cos
>
>Please fix this and the smatch issues and resubmit the other eight.
>
>Thanks,
>
>James
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[ANNOUNCE] python-sgutils 0.1

[Andy Grover]

Hi all,

Just a probably-premature announcement that I'm working on Python
bindings for sg3_utils's libsgutils2.so. The project is here:

https://github.com/agrover/python-sgutils

So far it supports inquiry, mode sense, readcap and report luns. I don't
think it makes sense to go for 100% SCSI cmd coverage (use sg3_utils for
that) but rather to do the parts that are most useful to Python-based
storage management tools.

License: BSD
Developing on Linux, but other platforms also likely to work.

Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] target: For iblock at default writecache enable.

[Nicholas A. Bellinger]

On Tue, 2013-01-29 at 15:04 -0800, Andy Grover wrote:
> On 01/29/2013 11:03 AM, Nicholas A. Bellinger wrote:
> 
> > So enabling emulate_write_cache=1 in the case when the underlying device
> > has not enabled it is incorrect.
> > 
> > I'd like to enable this bit when we know the underlying device has WCE=1
> > set, but currently there is not a way to determine this (generically)
> > from struct block_device.
> > 
> > So NACK for applying this until there is a method to determine what the
> > hardware below is doing.
> 
> This should be possible from userspace though. I'm planning on looking
> up underlying scsi device(s?) using libblkid, and then query the sense
> data using libsgutils when adding a block backstore in targetcli.
> 

Querying the mode pages from userspace would work for the SCSI backstore
case, but certainly not for raw block devices.

I'd still like to see this exposed to the block layer somehow, so that
the setting can be automatically determined by TCM once it's known if
the underlying HW has enabled write caching.

> It's kind of a hassle, but isn't it a huge performance win if we can
> enable this?
> 

Most certainly, but the danger is reporting WCE=1 (by default in all
cases) from TCM to the initiator when the underlying drives do not have
caching enabled.  Note that every spinning media device that I've ever
seen disables WCE by default from the factory.

--nab

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] target: For iblock at default writecache enable.

[Andy Grover]

On 01/29/2013 11:03 AM, Nicholas A. Bellinger wrote:

> So enabling emulate_write_cache=1 in the case when the underlying device
> has not enabled it is incorrect.
> 
> I'd like to enable this bit when we know the underlying device has WCE=1
> set, but currently there is not a way to determine this (generically)
> from struct block_device.
> 
> So NACK for applying this until there is a method to determine what the
> hardware below is doing.

This should be possible from userspace though. I'm planning on looking
up underlying scsi device(s?) using libblkid, and then query the sense
data using libsgutils when adding a block backstore in targetcli.

It's kind of a hassle, but isn't it a huge performance win if we can
enable this?

Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] target: Fix zero-length READ_CAPACITY_16 regression

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a regression introduced in v3.8-rc1 code where a
zero-length READ_CAPACITY_16 was no longer returning GOOD status, but
instead returning TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE to generate
a CHECK_CONDITION status.

This regression was introduced with the following commit:

  commit de103c93aff0bed0ae984274e5dc8b95899badab
  Author: Christoph Hellwig 
  Date:   Tue Nov 6 12:24:09 2012 -0800

  target: pass sense_reason as a return value

and this patch has been tested with the following zero-length CDB:

  sg_raw /dev/sdd 9e 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  SCSI Status: Good

  Sense Information:
  sense buffer empty

Also, convert sbc_emulate_readcapacity() to follow the same method
of handling transport_kmap_data_sg() return values, but we never
expect a zero-length request here.

Cc: Christoph Hellwig 
Cc: Paolo Bonzini 
Cc: Roland Dreier 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_sbc.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index 26a6d18..a664c66 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -58,11 +58,10 @@ sbc_emulate_readcapacity(struct se_cmd *cmd)
buf[7] = dev->dev_attrib.block_size & 0xff;
 
rbuf = transport_kmap_data_sg(cmd);
-   if (!rbuf)
-   return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
-
-   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
-   transport_kunmap_data_sg(cmd);
+   if (rbuf) {
+   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
+   transport_kunmap_data_sg(cmd);
+   }
 
target_complete_cmd(cmd, GOOD);
return 0;
@@ -97,11 +96,10 @@ sbc_emulate_readcapacity_16(struct se_cmd *cmd)
buf[14] = 0x80;
 
rbuf = transport_kmap_data_sg(cmd);
-   if (!rbuf)
-   return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
-
-   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
-   transport_kunmap_data_sg(cmd);
+   if (rbuf) {
+   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
+   transport_kunmap_data_sg(cmd);
+   }
 
target_complete_cmd(cmd, GOOD);
return 0;
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] target: Fix zero-length MODE_SENSE regression

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a regression introduced in v3.8-rc1 code where
a zero-length MODE_SENSE was no longer returning GOOD status, but
instead returning TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE to generate
a CHECK_CONDITION status.

This regression was introduced with the following commit:

  commit de103c93aff0bed0ae984274e5dc8b95899badab
  Author: Christoph Hellwig 
  Date:   Tue Nov 6 12:24:09 2012 -0800

  target: pass sense_reason as a return value

and this patch has been tested with the following zero-length CDB:

  sg_raw /dev/sdd 5a 00 0a 00 00 00 00 00 00 00
  SCSI Status: Good

  Sense Information:
  sense buffer empty

Cc: Christoph Hellwig 
Cc: Paolo Bonzini 
Cc: Roland Dreier 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_spc.c |   35 +++
 1 files changed, 7 insertions(+), 28 deletions(-)

diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index f8857d4..2d88f08 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -850,7 +850,7 @@ static sense_reason_t spc_emulate_modesense(struct se_cmd 
*cmd)
 {
struct se_device *dev = cmd->se_dev;
char *cdb = cmd->t_task_cdb;
-   unsigned char *buf, *map_buf;
+   unsigned char buf[SE_MODE_PAGE_BUF], *rbuf;
int type = dev->transport->get_device_type(dev);
int ten = (cmd->t_task_cdb[0] == MODE_SENSE_10);
bool dbd = !!(cdb[1] & 0x08);
@@ -862,26 +862,8 @@ static sense_reason_t spc_emulate_modesense(struct se_cmd 
*cmd)
int ret;
int i;
 
-   map_buf = transport_kmap_data_sg(cmd);
-   if (!map_buf)
-   return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
-   /*
-* If SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC is not set, then we
-* know we actually allocated a full page.  Otherwise, if the
-* data buffer is too small, allocate a temporary buffer so we
-* don't have to worry about overruns in all our INQUIRY
-* emulation handling.
-*/
-   if (cmd->data_length < SE_MODE_PAGE_BUF &&
-   (cmd->se_cmd_flags & SCF_PASSTHROUGH_SG_TO_MEM_NOALLOC)) {
-   buf = kzalloc(SE_MODE_PAGE_BUF, GFP_KERNEL);
-   if (!buf) {
-   transport_kunmap_data_sg(cmd);
-   return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
-   }
-   } else {
-   buf = map_buf;
-   }
+   memset(buf, 0, SE_MODE_PAGE_BUF);
+
/*
 * Skip over MODE DATA LENGTH + MEDIUM TYPE fields to byte 3 for
 * MODE_SENSE_10 and byte 2 for MODE_SENSE (6).
@@ -933,8 +915,6 @@ static sense_reason_t spc_emulate_modesense(struct se_cmd 
*cmd)
if (page == 0x3f) {
if (subpage != 0x00 && subpage != 0xff) {
pr_warn("MODE_SENSE: Invalid subpage code: 0x%02x\n", 
subpage);
-   kfree(buf);
-   transport_kunmap_data_sg(cmd);
return TCM_INVALID_CDB_FIELD;
}
 
@@ -971,7 +951,6 @@ static sense_reason_t spc_emulate_modesense(struct se_cmd 
*cmd)
pr_err("MODE SENSE: unimplemented page/subpage: 
0x%02x/0x%02x\n",
   page, subpage);
 
-   transport_kunmap_data_sg(cmd);
return TCM_UNKNOWN_MODE_PAGE;
 
 set_length:
@@ -980,12 +959,12 @@ set_length:
else
buf[0] = length - 1;
 
-   if (buf != map_buf) {
-   memcpy(map_buf, buf, cmd->data_length);
-   kfree(buf);
+   rbuf = transport_kmap_data_sg(cmd);
+   if (rbuf) {
+   memcpy(rbuf, buf, min_t(u32, SE_MODE_PAGE_BUF, 
cmd->data_length));
+   transport_kunmap_data_sg(cmd);
}
 
-   transport_kunmap_data_sg(cmd);
target_complete_cmd(cmd, GOOD);
return 0;
 }
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] target: Fix zero-length INQUIRY additional sense code regression

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

This patch fixes a minor regression introduced in v3.8-rc1 code
where a zero-length INQUIRY was no longer returning the correct
INVALID FIELD IN CDB additional sense code.

This regression was introduced with the following commit:

  commit de103c93aff0bed0ae984274e5dc8b95899badab
  Author: Christoph Hellwig 
  Date:   Tue Nov 6 12:24:09 2012 -0800

  target: pass sense_reason as a return value

and this patch has been tested with the following zero-length CDB:

  sg_raw /dev/sdd 12 00 83 00 00 00
  SCSI Status: Check Condition

  Sense Information:
   Fixed format, current;  Sense key: Illegal Request
   Additional sense: Invalid field in cdb

Cc: Christoph Hellwig 
Cc: Paolo Bonzini 
Cc: Roland Dreier 
Signed-off-by: Nicholas Bellinger 
---
 drivers/target/target_core_spc.c |9 -
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/target/target_core_spc.c b/drivers/target/target_core_spc.c
index 84f9e96..f8857d4 100644
--- a/drivers/target/target_core_spc.c
+++ b/drivers/target/target_core_spc.c
@@ -641,11 +641,10 @@ spc_emulate_inquiry(struct se_cmd *cmd)
 
 out:
rbuf = transport_kmap_data_sg(cmd);
-   if (!rbuf)
-   return TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
-
-   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
-   transport_kunmap_data_sg(cmd);
+   if (rbuf) {
+   memcpy(rbuf, buf, min_t(u32, sizeof(buf), cmd->data_length));
+   transport_kunmap_data_sg(cmd);
+   }
 
if (!ret)
target_complete_cmd(cmd, GOOD);
-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] target: Fix zero-length regressions in v3.8-rc1 code

[Nicholas A. Bellinger]

From: Nicholas Bellinger 

Hi folks,

The following are a handful of zero-length CDB regression bugfixes to address
breakage introduced by the recent sense_reason_t conversion in v3.8-rc1 code,
which incorrectly assumed CHECK_CONDITION status (in all CDB emulation cases)
when NULL was returned by transport_kmap_data_sg().

Please review, as I'd like to get these into v3.8-rc6.

Thank you,

--nab

Nicholas Bellinger (3):
  target: Fix zero-length INQUIRY additional sense code regression
  target: Fix zero-length MODE_SENSE regression
  target: Fix zero-length READ_CAPACITY_16 regression

 drivers/target/target_core_sbc.c |   18 +++
 drivers/target/target_core_spc.c |   44 +
 2 files changed, 19 insertions(+), 43 deletions(-)

-- 
1.7.2.5

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: storvsc loops with No Sense messages

[Olaf Hering]

On Tue, Jan 29, KY Srinivasan wrote:

> Was the installation done on a vhd or VHDX. I checked with Hyper-V
> guys and they say they never supported WRITE_SAME. I am wondering how
> it worked on ws2008.

Its a vhdx image, both fixed and dynamically size have the same issue.
I will see what happens with ws2008, at least the install proceeds
without issues. 


Also the unpatched kernel works fine in the installed system.

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: storvsc loops with No Sense messages

[KY Srinivasan]

Was the installation done on a vhd or VHDX. I checked with Hyper-V guys and 
they say they never supported WRITE_SAME. I am wondering how it worked on 
ws2008.

K. Y

> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, January 29, 2013 1:56 PM
> To: KY Srinivasan
> Cc: linux-scsi@vger.kernel.org
> Subject: Re: storvsc loops with No Sense messages
> 
> On Tue, Jan 29, KY Srinivasan wrote:
> 
> > I have not seen this. The SRB status indicates it is an illegal request; the
> command is WRITE_SAME. I will take a look.
> 
> I can ignore it like SET_WINDOW, and the installation proceeds.
> Just a few messages in dmesg:
> 
> ...
> [  107.448281] EXT4-fs (sda2): mounted filesystem with ordered data mode. 
> Opts:
> acl,user_xattr
> [  111.020383] sd 2:0:0:0: [sda] Unhandled error code
> [  111.020913] sd 2:0:0:0: [sda]
> [  111.021264] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [  111.021791] sd 2:0:0:0: [sda] CDB:
> [  111.022186] Write Same(10): 41 00 00 16 e3 a8 00 0f d8 00
> [  111.024400] end_request: I/O error, dev sda, sector 1500072
> [  111.025790] sda2: WRITE SAME failed. Manually zeroing.
> [  112.936342] sd 2:0:0:0: [sda] Unhandled error code
> [  112.937588] sd 2:0:0:0: [sda]
> [  112.938429] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [  112.939642] sd 2:0:0:0: [sda] CDB:
> [  112.940550] Write Same(10): 41 00 00 16 f3 80 00 0f e0 00
> [  112.945081] end_request: I/O error, dev sda, sector 1504128
> [  112.946627] sda2: WRITE SAME failed. Manually zeroing.
> [  113.495880] ISO 9660 Extensions: Microsoft Joliet Level 3
> [  113.498959] ISO 9660 Extensions: RRIP_1991A
> [  114.728274] sd 2:0:0:0: [sda] Unhandled error code
> [  114.729540] sd 2:0:0:0: [sda]
> [  114.730419] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [  114.731670] sd 2:0:0:0: [sda] CDB:
> [  114.732644] Write Same(10): 41 00 00 17 03 60 00 0f e0 00
> [  114.737219] end_request: I/O error, dev sda, sector 1508192
> [  114.739027] sda2: WRITE SAME failed. Manually zeroing.
> [  116.512217] sd 2:0:0:0: [sda] Unhandled error code
> [  116.513206] sd 2:0:0:0: [sda]
> [  116.513947] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
> [  116.515187] sd 2:0:0:0: [sda] CDB:
> [  116.515983] Write Same(10): 41 00 00 17 13 40 00 0f e0 00
> [  116.519547] end_request: I/O error, dev sda, sector 1512256
> [  116.521011] sda2: WRITE SAME failed. Manually zeroing.
> ...
> 
> Olaf
> 

N�r��yb�X��ǧv�^�)޺{.n�+{���"�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

[LSF/MM TOPIC] Making sure soft SCSI Targets are Valid

[Lee Duncan]

Hi:

I'm not sure if there is much interest in this, but I've recently
realized that there is no good free software to validate iSCSI targets,
not to mention FCOE targets, IB soft targets, etc. There's just no way
to know if any change you make is "legal" short of learning to speak
SCSI geek spec (or waiting to see what fails when you make a subtle change).

So I have been working with the (user-space) libiscsi creator and
maintainer, Ronnie Sahlberg, to enhance his test suite. But this only
addresses iSCSI targets. Some of his tests have already shown problems
like kernel panics when an incorrect bit is injected, showing the need
for such testing.

It occurs to me it would be most valuable if we had more generic SCSI
tests, not even limited to soft targets, available to developers and
manufacturers. How best to support such tests with our SCSI layer, and
what tests are needed now and in the future may be a good topic for
discussion.
-- 
Lee Duncan
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] target: For iblock at default writecache enable.

[Nicholas A. Bellinger]

Hi majianpeng,

On Fri, 2013-01-25 at 09:58 +0800, majianpeng wrote:
> Like the harddisk, at default write cache is enable.
> 
> Signed-off-by: Jianpeng Ma 
> ---
>  drivers/target/target_core_iblock.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/target/target_core_iblock.c 
> b/drivers/target/target_core_iblock.c
> index b526d23..69c2f2d 100644
> --- a/drivers/target/target_core_iblock.c
> +++ b/drivers/target/target_core_iblock.c
> @@ -125,6 +125,9 @@ static int iblock_configure_device(struct se_device *dev)
>   dev->dev_attrib.hw_max_sectors = UINT_MAX;
>   dev->dev_attrib.hw_queue_depth = q->nr_requests;
>  
> + /*Default enable write cache*/
> + dev->dev_attrib.emulate_write_cache = 1;
> +

So enabling emulate_write_cache=1 in the case when the underlying device
has not enabled it is incorrect.

I'd like to enable this bit when we know the underlying device has WCE=1
set, but currently there is not a way to determine this (generically)
from struct block_device.

So NACK for applying this until there is a method to determine what the
hardware below is doing.

--nab

>   /*
>* Check if the underlying struct block_device request_queue supports
>* the QUEUE_FLAG_DISCARD bit for UNMAP/WRITE_SAME in SCSI + TRIM
> -- 
> 1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: storvsc loops with No Sense messages

[Olaf Hering]

On Tue, Jan 29, KY Srinivasan wrote:

> I have not seen this. The SRB status indicates it is an illegal request; the 
> command is WRITE_SAME. I will take a look.

I can ignore it like SET_WINDOW, and the installation proceeds.
Just a few messages in dmesg:

...
[  107.448281] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
acl,user_xattr
[  111.020383] sd 2:0:0:0: [sda] Unhandled error code
[  111.020913] sd 2:0:0:0: [sda]
[  111.021264] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  111.021791] sd 2:0:0:0: [sda] CDB:
[  111.022186] Write Same(10): 41 00 00 16 e3 a8 00 0f d8 00
[  111.024400] end_request: I/O error, dev sda, sector 1500072
[  111.025790] sda2: WRITE SAME failed. Manually zeroing.
[  112.936342] sd 2:0:0:0: [sda] Unhandled error code
[  112.937588] sd 2:0:0:0: [sda]
[  112.938429] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  112.939642] sd 2:0:0:0: [sda] CDB:
[  112.940550] Write Same(10): 41 00 00 16 f3 80 00 0f e0 00
[  112.945081] end_request: I/O error, dev sda, sector 1504128
[  112.946627] sda2: WRITE SAME failed. Manually zeroing.
[  113.495880] ISO 9660 Extensions: Microsoft Joliet Level 3
[  113.498959] ISO 9660 Extensions: RRIP_1991A
[  114.728274] sd 2:0:0:0: [sda] Unhandled error code
[  114.729540] sd 2:0:0:0: [sda]
[  114.730419] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  114.731670] sd 2:0:0:0: [sda] CDB:
[  114.732644] Write Same(10): 41 00 00 17 03 60 00 0f e0 00
[  114.737219] end_request: I/O error, dev sda, sector 1508192
[  114.739027] sda2: WRITE SAME failed. Manually zeroing.
[  116.512217] sd 2:0:0:0: [sda] Unhandled error code
[  116.513206] sd 2:0:0:0: [sda]
[  116.513947] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
[  116.515187] sd 2:0:0:0: [sda] CDB:
[  116.515983] Write Same(10): 41 00 00 17 13 40 00 0f e0 00
[  116.519547] end_request: I/O error, dev sda, sector 1512256
[  116.521011] sda2: WRITE SAME failed. Manually zeroing.
...

Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mvsas: fixed timeout issue when removing module

[yxlraid]

From: Xiangliang Yu 

- Root cause is libsas will clear asd_sas_port
  phy_mask value in sas_port_deform after triggering
  destruct workqueue, but the workqueue will send
  sync cmd and still need phy_mask value.
  Now, mvsas using asd_sas_phy setting instead of
  asd_sas_port setting.
---
 drivers/scsi/mvsas/mv_sas.c |   10 --
 drivers/scsi/mvsas/mv_sas.h |1 +
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mvsas/mv_sas.c b/drivers/scsi/mvsas/mv_sas.c
index 078c639..532110f 100644
--- a/drivers/scsi/mvsas/mv_sas.c
+++ b/drivers/scsi/mvsas/mv_sas.c
@@ -316,10 +316,13 @@ static int mvs_task_prep_smp(struct mvs_info *mvi,
 struct mvs_task_exec_info *tei)
 {
int elem, rc, i;
+   struct sas_ha_struct *sha = mvi->sas;
struct sas_task *task = tei->task;
struct mvs_cmd_hdr *hdr = tei->hdr;
struct domain_device *dev = task->dev;
struct asd_sas_port *sas_port = dev->port;
+   struct sas_phy *sphy = dev->phy;
+   struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];
struct scatterlist *sg_req, *sg_resp;
u32 req_len, resp_len, tag = tei->tag;
void *buf_tmp;
@@ -392,7 +395,7 @@ static int mvs_task_prep_smp(struct mvs_info *mvi,
slot->tx = mvi->tx_prod;
mvi->tx[mvi->tx_prod] = cpu_to_le32((TXQ_CMD_SMP << TXQ_CMD_SHIFT) |
TXQ_MODE_I | tag |
-   (sas_port->phy_mask << TXQ_PHY_SHIFT));
+   (MVS_PHY_ID << TXQ_PHY_SHIFT));
 
hdr->flags |= flags;
hdr->lens = cpu_to_le32(((resp_len / 4) << 16) | ((req_len - 4) / 4));
@@ -438,11 +441,14 @@ static u32 mvs_get_ncq_tag(struct sas_task *task, u32 
*tag)
 static int mvs_task_prep_ata(struct mvs_info *mvi,
 struct mvs_task_exec_info *tei)
 {
+   struct sas_ha_struct *sha = mvi->sas;
struct sas_task *task = tei->task;
struct domain_device *dev = task->dev;
struct mvs_device *mvi_dev = dev->lldd_dev;
struct mvs_cmd_hdr *hdr = tei->hdr;
struct asd_sas_port *sas_port = dev->port;
+   struct sas_phy *sphy = dev->phy;
+   struct asd_sas_phy *sas_phy = sha->sas_phy[sphy->number];
struct mvs_slot_info *slot;
void *buf_prd;
u32 tag = tei->tag, hdr_tag;
@@ -462,7 +468,7 @@ static int mvs_task_prep_ata(struct mvs_info *mvi,
slot->tx = mvi->tx_prod;
del_q = TXQ_MODE_I | tag |
(TXQ_CMD_STP << TXQ_CMD_SHIFT) |
-   (sas_port->phy_mask << TXQ_PHY_SHIFT) |
+   (MVS_PHY_ID << TXQ_PHY_SHIFT) |
(mvi_dev->taskfileset << TXQ_SRS_SHIFT);
mvi->tx[mvi->tx_prod] = cpu_to_le32(del_q);
 
diff --git a/drivers/scsi/mvsas/mv_sas.h b/drivers/scsi/mvsas/mv_sas.h
index 2ae77a0..9f3cc13 100644
--- a/drivers/scsi/mvsas/mv_sas.h
+++ b/drivers/scsi/mvsas/mv_sas.h
@@ -76,6 +76,7 @@ extern struct kmem_cache *mvs_task_list_cache;
(__mc) != 0 ;   \
(++__lseq), (__mc) >>= 1)
 
+#define MVS_PHY_ID (1U << sas_phy->id)
 #define MV_INIT_DELAYED_WORK(w, f, d)  INIT_DELAYED_WORK(w, f)
 #define UNASSOC_D2H_FIS(id)\
((void *) mvi->rx_fis + 0x100 * id)
-- 
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: storvsc loops with No Sense messages

[KY Srinivasan]

> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: Tuesday, January 29, 2013 10:28 AM
> To: KY Srinivasan
> Cc: linux-scsi@vger.kernel.org
> Subject: storvsc loops with No Sense messages
> 
> 
> KY,
> 
> while attempting to install the upcoming openSuSE 12.3 in a hyper-v
> guest (1 vcpu, 512MB) hosted on Windows Server 2012 I see a hanging
> guest after formating the root partition, when the installer starts to
> write files to it.  After booting the install kernel with
> 'ignore_loglevel' I see a flood of the "No Sense" messages shown below.
> I can reproduce it every time with 12.3.
> 
> The sglist init patch does not fix it for me.
> 
> Hannes did many storage related backports for SLES11 SP3, and sometimes
> the installer hangs at similar points during a fresh SP3 install.
> 
> The same procedure works fine on Windows Server 2008.
> 
> Any ideas what 2012 does differently? It happens with a plain 3.7.n
> kernel. I will try 3.8-rc now, and see if it happens as well.
> 
> Olaf
> 
> ...
> [0.00] Linux version 3.7.5-5.home_olh_12_3-vanilla (geeko@buildhost)
> (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1
> SMP Mon Jan 28 12:39:46 UTC 2013 (d9a9e6d)
> [0.00] Command line: quiet panic=9 sysrq=yes start_shell splash=silent
> vga=0x317 video=1024x768 console=ttyS0,115200 console=tty1 ignore_loglevel
> initrd=sl/12.3/initrd-x86_64 BOOT_IMAGE=sl/12.3/linux-x86_64
> ...
> [7.938806] scsi2 : storvsc_host_t
> [7.940709] scsi 2:0:0:0: Direct-Access Msft Virtual Disk 1.0  
> PQ: 0 ANSI: 4
> [7.943952] sd 2:0:0:0: Attached scsi generic sg1 type 0
> 
> [7.946440] sd 2:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 
> GB/10.0 GiB)
> [7.949485] sd 2:0:0:0: [sda] Write Protect is off
> [7.951231] sd 2:0:0:0: [sda] Mode Sense: 0f 00 00 00
> [7.953105] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
> doesn't
> support DPO or FUA
> [7.955269] scsi3 : storvsc_host_t
> [7.957027] scsi scan: INQUIRY result too short (5), using 36
> [7.958786] scsi scan: INQUIRY result too short (5), using 36
> [7.961292] input: Microsoft Vmbus HID-compliant Mouse as
> /devices/virtual/input/input3
> [7.965400] hid-generic 0006:045E:0621.0001: input:  HID v0.01
> Mouse [Microsoft Vmbus HID-compliant Mouse] on
> [7.971872] hv_netvsc: hv_netvsc channel opened successfully
> [7.974574] hv_netvsc vmbus_0_11: Device MAC 00:15:5d:02:51:02 link state 
> up
> [7.985086]  sda: sda1 sda2
> [7.986725] sd 2:0:0:0: [sda] Attached SCSI disk
> ...
> [  156.205185] Adding 746492k swap on /dev/sda1.  Priority:-1 extents:1
> across:746492k
> ...
> [  156.478186] EXT4-fs (sda2): mounted filesystem with ordered data mode. 
> Opts:
> acl,user_xattr
> [  161.459523] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
> [  161.462157] sd 2:0:0:0: [sda]
> [  161.463135] Sense Key : No Sense [current]
> [  161.464983] sd 2:0:0:0: [sda]
> [  161.465899] Add. Sense: No additional sense information
> [  161.468211] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
> [  161.475766] sd 2:0:0:0: [sda]
> [  161.476728] Sense Key : No Sense [current]
> [  161.478284] sd 2:0:0:0: [sda]
> [  161.479441] Add. Sense: No additional sense information
> [  161.481311] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
> [  161.484477] sd 2:0:0:0: [sda]
> [  161.485422] Sense Key : No Sense [current]
> [  161.486977] sd 2:0:0:0: [sda]
> [  161.487920] Add. Sense: No additional sense information
> 
> ... and so it goes on until the VM is powered off.

Olaf,

I have not seen this. The SRB status indicates it is an illegal request; the 
command is WRITE_SAME. I will take a look.

K. Y
> 
> 

N�r��yb�X��ǧv�^�)޺{.n�+{���"�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

storvsc loops with No Sense messages

[Olaf Hering]

KY,

while attempting to install the upcoming openSuSE 12.3 in a hyper-v
guest (1 vcpu, 512MB) hosted on Windows Server 2012 I see a hanging
guest after formating the root partition, when the installer starts to
write files to it.  After booting the install kernel with
'ignore_loglevel' I see a flood of the "No Sense" messages shown below.
I can reproduce it every time with 12.3.

The sglist init patch does not fix it for me.

Hannes did many storage related backports for SLES11 SP3, and sometimes
the installer hangs at similar points during a fresh SP3 install.

The same procedure works fine on Windows Server 2008.

Any ideas what 2012 does differently? It happens with a plain 3.7.n
kernel. I will try 3.8-rc now, and see if it happens as well.

Olaf

...
[0.00] Linux version 3.7.5-5.home_olh_12_3-vanilla (geeko@buildhost) 
(gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 
SMP Mon Jan 28 12:39:46 UTC 2013 (d9a9e6d)
[0.00] Command line: quiet panic=9 sysrq=yes start_shell splash=silent 
vga=0x317 video=1024x768 console=ttyS0,115200 console=tty1 ignore_loglevel 
initrd=sl/12.3/initrd-x86_64 BOOT_IMAGE=sl/12.3/linux-x86_64
...
[7.938806] scsi2 : storvsc_host_t
[7.940709] scsi 2:0:0:0: Direct-Access Msft Virtual Disk 1.0  
PQ: 0 ANSI: 4
[7.943952] sd 2:0:0:0: Attached scsi generic sg1 type 0

[7.946440] sd 2:0:0:0: [sda] 20971520 512-byte logical blocks: (10.7 
GB/10.0 GiB)
[7.949485] sd 2:0:0:0: [sda] Write Protect is off
[7.951231] sd 2:0:0:0: [sda] Mode Sense: 0f 00 00 00
[7.953105] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[7.955269] scsi3 : storvsc_host_t
[7.957027] scsi scan: INQUIRY result too short (5), using 36
[7.958786] scsi scan: INQUIRY result too short (5), using 36
[7.961292] input: Microsoft Vmbus HID-compliant Mouse as 
/devices/virtual/input/input3
[7.965400] hid-generic 0006:045E:0621.0001: input:  HID v0.01 
Mouse [Microsoft Vmbus HID-compliant Mouse] on
[7.971872] hv_netvsc: hv_netvsc channel opened successfully
[7.974574] hv_netvsc vmbus_0_11: Device MAC 00:15:5d:02:51:02 link state up
[7.985086]  sda: sda1 sda2
[7.986725] sd 2:0:0:0: [sda] Attached SCSI disk
...
[  156.205185] Adding 746492k swap on /dev/sda1.  Priority:-1 extents:1 
across:746492k
...
[  156.478186] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
acl,user_xattr
[  161.459523] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
[  161.462157] sd 2:0:0:0: [sda]
[  161.463135] Sense Key : No Sense [current]
[  161.464983] sd 2:0:0:0: [sda]
[  161.465899] Add. Sense: No additional sense information
[  161.468211] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
[  161.475766] sd 2:0:0:0: [sda]
[  161.476728] Sense Key : No Sense [current]
[  161.478284] sd 2:0:0:0: [sda]
[  161.479441] Add. Sense: No additional sense information
[  161.481311] hv_storvsc vmbus_0_1: cmd 0x41 scsi status 0x2 srb status 0x6
[  161.484477] sd 2:0:0:0: [sda]
[  161.485422] Sense Key : No Sense [current]
[  161.486977] sd 2:0:0:0: [sda]
[  161.487920] Add. Sense: No additional sense information

... and so it goes on until the VM is powered off.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] block: fix ext_devt_idr handling

[Tomas Henzl]

While adding and removing a lot of disks disks and partitions this sometimes
shows up -
WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted)
Hardware name:
sysfs: cannot create duplicate filename '/dev/block/259:751'
Modules linked in: raid1 autofs4 bnx2fc cnic uio fcoe libfcoe libfc 8021q 
scsi_transport_fc scsi_tgt garp stp llc sunrpc cpufreq_ondemand powernow_k8 
freq_table mperf ipv6 dm_mirror dm_region_hash dm_log power_meter microcode 
dcdbas serio_raw amd64_edac_mod edac_core edac_mce_amd i2c_piix4 i2c_core 
k10temp bnx2 sg ixgbe dca mdio ext4 mbcache jbd2 dm_round_robin sr_mod cdrom 
sd_mod crc_t10dif ata_generic pata_acpi pata_atiixp ahci mptsas mptscsih 
mptbase scsi_transport_sas dm_multipath dm_mod [last unloaded: scsi_wait_scan]
Pid: 44103, comm: async/16 Not tainted 2.6.32-195.el6.x86_64 #1
Call Trace:
 [] ? warn_slowpath_common+0x87/0xc0
 [] ? warn_slowpath_fmt+0x46/0x50
 [] ? sysfs_add_one+0xc9/0x130
 [] ? sysfs_do_create_link+0x12b/0x170
 [] ? sysfs_create_link+0x13/0x20
 [] ? device_add+0x317/0x650
 [] ? idr_get_new+0x13/0x50
 [] ? add_partition+0x21c/0x390
 [] ? rescan_partitions+0x32b/0x470
 [] ? sd_open+0x81/0x1f0 [sd_mod]
 [] ? __blkdev_get+0x1b6/0x3c0
 [] ? blkdev_get+0x10/0x20
 [] ? register_disk+0x155/0x170
 [] ? add_disk+0xa6/0x160
 [] ? sd_probe_async+0x13b/0x210 [sd_mod]
 [] ? add_wait_queue+0x46/0x60
 [] ? async_thread+0x102/0x250
 [] ? default_wake_function+0x0/0x20
 [] ? async_thread+0x0/0x250
 [] ? kthread+0x96/0xa0
 [] ? child_rip+0xa/0x20
 [] ? kthread+0x0/0xa0
 [] ? child_rip+0x0/0x20
This most likely happens because dev_t is freed before while the number is 
still used
and idr_get_new is not protected on every use. The fix adds a mutex where
it wasn't before and moves the dev_t free function so it is called after
device del.

Signed-off-by: Tomas Henzl 
---
 block/genhd.c | 6 +-
 block/partition-generic.c | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 9cf5583..9433636 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -420,14 +420,18 @@ int blk_alloc_devt(struct hd_struct *part, dev_t *devt)
do {
if (!idr_pre_get(&ext_devt_idr, GFP_KERNEL))
return -ENOMEM;
+   mutex_lock(&ext_devt_mutex);
rc = idr_get_new(&ext_devt_idr, part, &idx);
+   mutex_unlock(&ext_devt_mutex);
} while (rc == -EAGAIN);
 
if (rc)
return rc;
 
if (idx > MAX_EXT_DEVT) {
+   mutex_lock(&ext_devt_mutex);
idr_remove(&ext_devt_idr, idx);
+   mutex_unlock(&ext_devt_mutex);
return -EBUSY;
}
 
@@ -644,7 +648,6 @@ void del_gendisk(struct gendisk *disk)
disk_part_iter_exit(&piter);
 
invalidate_partition(disk, 0);
-   blk_free_devt(disk_to_dev(disk)->devt);
set_capacity(disk, 0);
disk->flags &= ~GENHD_FL_UP;
 
@@ -662,6 +665,7 @@ void del_gendisk(struct gendisk *disk)
if (!sysfs_deprecated)
sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk)));
device_del(disk_to_dev(disk));
+   blk_free_devt(disk_to_dev(disk)->devt);
 }
 EXPORT_SYMBOL(del_gendisk);
 
diff --git a/block/partition-generic.c b/block/partition-generic.c
index 6df5d69..7b8b8d1 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -249,11 +249,11 @@ void delete_partition(struct gendisk *disk, int partno)
if (!part)
return;
 
-   blk_free_devt(part_devt(part));
rcu_assign_pointer(ptbl->part[partno], NULL);
rcu_assign_pointer(ptbl->last_lookup, NULL);
kobject_put(part->holder_dir);
device_del(part_to_dev(part));
+   blk_free_devt(part_devt(part));
 
hd_struct_put(part);
 }
-- 
1.7.11.7


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [SCSI] advansys: change buildtime warning into runtime error

[Paul Bolle]

On Mon, 2012-11-05 at 11:58 +0100, Paul Bolle wrote:
> Building advansys.o triggers this warning:
> drivers/scsi/advansys.c:71:2: warning: #warning this driver is still not 
> properly converted to the DMA API [-Wcpp]
> 
> This warning can be traced back to a patch called "advansys: add warning
> and convert #includes" which was included in v2.6.10. That patch also
> marked the driver as BROKEN.
> 
> Commit 4661e3eace2c7b8433476b5bf0ee437ab3c7dfd4 ("[SCSI] advansys
> driver: limp along on x86") enabled this driver for x86-32. And commit
> 9d511a4b29de6764931343d03e493f2e04df0271 ("[SCSI] advansys: Changes to
> work on parisc") enabled this driver for all architectures. But the
> commit explanation stated:
> I haven't removed the #warning yet because virt_to_bus/bus_to_virt are
> only eliminated for narrow boards.  Wide boards need more work.
> 
> Five years have passed and, apparently, those wide boards still need
> more work. So let's change the buildtime warning into a runtime error,
> only printed for those wide boards. Perhaps that might push the people
> using those wide boards to convert this driver. And for all others
> there's now one less buildtime warning to ignore.
> 
> Signed-off-by: Paul Bolle 
> ---
> Compile tested only. I don't have any AdvanSys SCSI boards (neither
> narrow nor wide).

The date of this message suggests I submitted this patch for a warning
seen while building v3.7-rc4. An identical warning can be seen while
building v3.8-rc5. What's the status of my patch? Did anyone find some
time to have a look at it?


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] aic7xxx_old: silence GCC warnings

[Paul Bolle]

On Mon, 2012-10-29 at 13:45 +0100, Paul Bolle wrote:
> On Mon, 2012-10-29 at 12:17 +, James Bottomley wrote:
> > mvsas has a maintainer: poke them harder
> 
> According to MAINTAINERS that's you. Is Xiangliang Yu perhaps the actual
> maintainer?

Building the mvsas driver triggers identical warnings in v3.8-rc5:
drivers/scsi/mvsas/mv_sas.c: In function ‘mvs_update_phyinfo’:
drivers/scsi/mvsas/mv_sas.c:1156:34: warning: comparison between ‘enum 
sas_device_type’ and ‘enum sas_dev_type’ [-Wenum-compare]
drivers/scsi/mvsas/mv_sas.c:1159:39: warning: comparison between ‘enum 
sas_device_type’ and ‘enum sas_dev_type’ [-Wenum-compare]

And according to MAINTAINERS you're still the maintainer. So I'd guess
I'm poking the maintainer now.


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] qla2xxx: silence two GCC warnings

[Paul Bolle]

On Mon, 2012-10-08 at 11:15 -0500, Saurav Kashyap wrote:
> Acked-by: Saurav Kashyap 
> 
> Thanks,
> ~Saurav
> 
> >Compiling qla_gs.o (part of the qla2xxx module) triggers two GCC
> >warnings:
> >drivers/scsi/qla2xxx/qla_gs.c: In function Œqla2x00_fdmi_rhba¹:
> >drivers/scsi/qla2xxx/qla_gs.c:1339:7: warning: array subscript is
> >above array bounds [-Warray-bounds]
> >drivers/scsi/qla2xxx/qla_gs.c: In function Œqla2x00_fdmi_register¹:
> >drivers/scsi/qla2xxx/qla_gs.c:1663:15: warning: array subscript is
> >above array bounds [-Warray-bounds]

This patch was originally posted to silence two GCC warnings while
building v3.6-rc7. Basically identical warnings can still be seen while
building v3.8-rc5. What's the status of this patch?


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[LSF/MM TOPIC] Thin provisioning SOFT_THRESHOLD error handling

[Hannes Reinecke]

Hi all,

Thin-provisioned devices have the ability to set a 'soft threshold', 
which is triggered if the real free space for this device is beyond 
this mark.


The intention behind this is to allow the system to induce some 
garbage collection with possibly freeing up unused space.


Initially it would be possible to execute garbage collection on 
filesystems (eg for btrfs).


However, as this concept applies to other areas within the kernel
(like dm-thinp or even btrfs itself) it might be an idea to have
a general mechanism / error handling etc in place.

I would like to discuss at LSF the possible implementations
and handling mechanism for this kind of failure scenarios.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html