Re: [PATCH] scsi/qla2xxx: label endian-ness for many fields

[Joe Perches]

On Fri, 2016-12-09 at 22:45 +0200, Michael S. Tsirkin wrote:
> This adds endian-ness labels for lots of qla structs.
> Doing this cuts down number of sparse warnings from ~1700 to ~1400.
> Will help find and resolve some of real issues down the road.
> 
> Signed-off-by: Michael S. Tsirkin 
> 
> ---
> 
> Compile-tested only.
> 
> diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
> index 73b12e4..a4d3071 100644
> --- a/drivers/scsi/qla2xxx/qla_def.h
> +++ b/drivers/scsi/qla2xxx/qla_def.h
> @@ -1159,28 +1159,28 @@ typedef struct {
>*/
>   uint8_t  firmware_options[2];
>  
> - uint16_t frame_payload_size;
> - uint16_t max_iocb_allocation;
> - uint16_t execution_throttle;
> + __le16 frame_payload_size;
> + __le16 max_iocb_allocation;
> + __le16 execution_throttle;

Shouldn't all these _not_ have the leading __?
Perhaps the uint8_t uses should be converted to u8 as well.

[etc...]

--
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 v4 4/6] qla2xxx: Add multiple queue pair functionality.

[Madhani, Himanshu]

Hi Martin, 



On 12/9/16, 11:39 AM, "Madhani, Himanshu"  wrote:

>
>On 12/9/16, 5:10 AM, "Christoph Hellwig"  wrote:
>
>>Ok.  We'll still need to use PCI_IRQ_AFFINITY here after it's removed
>>i nthe previous patch, but with pci_irq_alloc_vectors_affinity so that
>>we can get the separate non-assignment vector right as in the previous
>>discussion.
>
>Ack. Will fix up patch and resend series.

Would you be pulling changes for this new call into scsi tree anytime soon

https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=irq/for-block

>
>Thanks,
>- Himanshu
>


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

RE: [PATCH] aacraid: remove wildcard for series 9 controllers

[Don Brace]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Thursday, December 08, 2016 4:10 PM
> To: Don Brace
> Cc: j...@linux.vnet.ibm.com; John Hall; Kevin Barnett; Mahesh
> Rajashekhara; Bader Ali-saleh; h...@infradead.org; Scott Teel; Viswas G;
> Justin Lindley; Scott Benesh; elli...@hpe.com; posw...@suse.com; linux-
> s...@vger.kernel.org
> Subject: Re: [PATCH] aacraid: remove wildcard for series 9 controllers
> 
> EXTERNAL EMAIL
> 
> 
> > "Don" == Don Brace  writes:
> 
> Applied to 4.10/scsi-queue.
> 
> --
> Martin K. Petersen  Oracle Linux Engineering

Can this patch still make into 4.9?
Thanks,
Don Brace

--
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] ibmvscsi: add write memory barrier to CRQ processing

[Benjamin Herrenschmidt]

On Wed, 2016-12-07 at 17:31 -0600, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a memory barrier after this write to ensure
> no other stores are reordered when updating the valid byte.

Which "other stores" specifically ? This smells fishy without that
precision. It's important to always understand what exactly barriers
order with.

Cheers,
Ben.

> Signed-off-by: Tyrel Datwyler 
> ---
>  drivers/scsi/ibmvscsi/ibmvscsi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c 
> b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index d9534ee..2f5b07e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -232,6 +232,7 @@ static void ibmvscsi_task(void *data)
> >     while ((crq = crq_queue_next_crq(>queue)) != NULL) {
> >     ibmvscsi_handle_crq(crq, hostdata);
> >     crq->valid = VIOSRP_CRQ_FREE;
> > +   wmb();
> >     }
>  
> >     vio_enable_interrupts(vdev);
> @@ -240,6 +241,7 @@ static void ibmvscsi_task(void *data)
> >     vio_disable_interrupts(vdev);
> >     ibmvscsi_handle_crq(crq, hostdata);
> >     crq->valid = VIOSRP_CRQ_FREE;
> > +   wmb();
> >     } else {
> >     done = 1;
> >     }

--
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/qla2xxx: label endian-ness for many fields

[Madhani, Himanshu]

On 12/9/16, 12:45 PM, "Michael S. Tsirkin"  wrote:

>This adds endian-ness labels for lots of qla structs.
>Doing this cuts down number of sparse warnings from ~1700 to ~1400.
>Will help find and resolve some of real issues down the road.
>
>Signed-off-by: Michael S. Tsirkin 
>
>---
>
>Compile-tested only.

We’ll review and run regression test with this change and update. 

Thanks,
- Himanshu

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

Re: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Michael S. Tsirkin]

On Fri, Dec 09, 2016 at 03:18:02PM +, Bart Van Assche wrote:
> On 12/08/16 22:40, Madhani, Himanshu wrote:
> > We’ll take a look and send patches to resolve these warnings.
> 
> Thanks!
> 
> Bart.
> 

Sounds good. I posted what I have so far so that you can
start from that.

-- 
MST
--
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/qla2xxx: label endian-ness for many fields

[Michael S. Tsirkin]

This adds endian-ness labels for lots of qla structs.
Doing this cuts down number of sparse warnings from ~1700 to ~1400.
Will help find and resolve some of real issues down the road.

Signed-off-by: Michael S. Tsirkin 

---

Compile-tested only.

diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index 73b12e4..a4d3071 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -1159,28 +1159,28 @@ typedef struct {
 */
uint8_t  firmware_options[2];
 
-   uint16_t frame_payload_size;
-   uint16_t max_iocb_allocation;
-   uint16_t execution_throttle;
+   __le16 frame_payload_size;
+   __le16 max_iocb_allocation;
+   __le16 execution_throttle;
uint8_t  retry_count;
uint8_t  retry_delay;   /* unused */
uint8_t  port_name[WWN_SIZE];   /* Big endian. */
-   uint16_t hard_address;
+   __le16 hard_address;
uint8_t  inquiry_data;
uint8_t  login_timeout;
uint8_t  node_name[WWN_SIZE];   /* Big endian. */
 
-   uint16_t request_q_outpointer;
-   uint16_t response_q_inpointer;
-   uint16_t request_q_length;
-   uint16_t response_q_length;
-   uint32_t request_q_address[2];
-   uint32_t response_q_address[2];
+   __le16 request_q_outpointer;
+   __le16 response_q_inpointer;
+   __le16 request_q_length;
+   __le16 response_q_length;
+   __le32 request_q_address[2];
+   __le32 response_q_address[2];
 
-   uint16_t lun_enables;
+   __le16 lun_enables;
uint8_t  command_resource_count;
uint8_t  immediate_notify_resource_count;
-   uint16_t timeout;
+   __le16 timeout;
uint8_t  reserved_2[2];
 
/*
@@ -1238,48 +1238,48 @@ typedef struct {
 #define GLSO_USE_DID   BIT_3
 
 struct link_statistics {
-   uint32_t link_fail_cnt;
-   uint32_t loss_sync_cnt;
-   uint32_t loss_sig_cnt;
-   uint32_t prim_seq_err_cnt;
-   uint32_t inval_xmit_word_cnt;
-   uint32_t inval_crc_cnt;
-   uint32_t lip_cnt;
-   uint32_t link_up_cnt;
-   uint32_t link_down_loop_init_tmo;
-   uint32_t link_down_los;
-   uint32_t link_down_loss_rcv_clk;
-   uint32_t reserved0[5];
-   uint32_t port_cfg_chg;
-   uint32_t reserved1[11];
-   uint32_t rsp_q_full;
-   uint32_t atio_q_full;
-   uint32_t drop_ae;
-   uint32_t els_proto_err;
-   uint32_t reserved2;
-   uint32_t tx_frames;
-   uint32_t rx_frames;
-   uint32_t discarded_frames;
-   uint32_t dropped_frames;
-   uint32_t reserved3;
-   uint32_t nos_rcvd;
-   uint32_t reserved4[4];
-   uint32_t tx_prjt;
-   uint32_t rcv_exfail;
-   uint32_t rcv_abts;
-   uint32_t seq_frm_miss;
-   uint32_t corr_err;
-   uint32_t mb_rqst;
-   uint32_t nport_full;
-   uint32_t eofa;
-   uint32_t reserved5;
-   uint32_t fpm_recv_word_cnt_lo;
-   uint32_t fpm_recv_word_cnt_hi;
-   uint32_t fpm_disc_word_cnt_lo;
-   uint32_t fpm_disc_word_cnt_hi;
-   uint32_t fpm_xmit_word_cnt_lo;
-   uint32_t fpm_xmit_word_cnt_hi;
-   uint32_t reserved6[70];
+   __le32 link_fail_cnt;
+   __le32 loss_sync_cnt;
+   __le32 loss_sig_cnt;
+   __le32 prim_seq_err_cnt;
+   __le32 inval_xmit_word_cnt;
+   __le32 inval_crc_cnt;
+   __le32 lip_cnt;
+   __le32 link_up_cnt;
+   __le32 link_down_loop_init_tmo;
+   __le32 link_down_los;
+   __le32 link_down_loss_rcv_clk;
+   __le32 reserved0[5];
+   __le32 port_cfg_chg;
+   __le32 reserved1[11];
+   __le32 rsp_q_full;
+   __le32 atio_q_full;
+   __le32 drop_ae;
+   __le32 els_proto_err;
+   __le32 reserved2;
+   __le32 tx_frames;
+   __le32 rx_frames;
+   __le32 discarded_frames;
+   __le32 dropped_frames;
+   __le32 reserved3;
+   __le32 nos_rcvd;
+   __le32 reserved4[4];
+   __le32 tx_prjt;
+   __le32 rcv_exfail;
+   __le32 rcv_abts;
+   __le32 seq_frm_miss;
+   __le32 corr_err;
+   __le32 mb_rqst;
+   __le32 nport_full;
+   __le32 eofa;
+   __le32 reserved5;
+   __le32 fpm_recv_word_cnt_lo;
+   __le32 fpm_recv_word_cnt_hi;
+   __le32 fpm_disc_word_cnt_lo;
+   __le32 fpm_disc_word_cnt_hi;
+   __le32 fpm_xmit_word_cnt_lo;
+   __le32 fpm_xmit_word_cnt_hi;
+   __le32 reserved6[70];
 };
 
 /*
@@ -1330,13 +1330,13 @@ typedef struct {
 */
uint8_t  firmware_options[2];
 
-   uint16_t frame_payload_size;
-   uint16_t max_iocb_allocation;
-   uint16_t execution_throttle;
+   __le16 frame_payload_size;
+   __le16 max_iocb_allocation;
+   __le16 execution_throttle;
uint8_t  retry_count;
uint8_t  retry_delay;   /* unused */
uint8_t  port_name[WWN_SIZE];   /* Big endian. */
-   uint16_t hard_address;
+   __le16 

Re: [PATCH v4 4/6] qla2xxx: Add multiple queue pair functionality.

[Madhani, Himanshu]

On 12/9/16, 5:10 AM, "Christoph Hellwig"  wrote:

>Ok.  We'll still need to use PCI_IRQ_AFFINITY here after it's removed
>i nthe previous patch, but with pci_irq_alloc_vectors_affinity so that
>we can get the separate non-assignment vector right as in the previous
>discussion.

Ack. Will fix up patch and resend series.

Thanks,
- Himanshu

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

Re: [PATCH 16/22] qla2xxx: Improve RSCN handling in driver

[Madhani, Himanshu]

Hi Hannes, 




On 12/7/16, 3:32 AM, "Hannes Reinecke"  wrote:

>This is a bit odd.
>If you already have code for fixing the to-do, why is the to-do there?
>And if the code doesn't work, what's the point of including it here?
>
>I would suggest removing the code; the comment should be giving enough
>of a hint of what needs to be implemented.

Thanks for the review comments. This is one looks like got left off. 
We’ll fix this code and resubmit this series.

Thanks,
- Himanshu
>

[PATCH RESEND] Update 3ware driver email addresses

[adam radford]

This change updates the 3ware drivers (3w-, 3w-9xxx, 3w-sas) email
addresses from linuxr...@lsi.com to aradf...@gmail.com, since the old
email address doesn't exist.

This patch was updated to remove www.lsi.com text.

Signed-off-by: Adam Radford 
---
 MAINTAINERS| 2 +-
 drivers/scsi/3w-9xxx.c | 9 +++--
 drivers/scsi/3w-9xxx.h | 9 +++--
 drivers/scsi/3w-sas.c  | 7 ++-
 drivers/scsi/3w-sas.h  | 7 ++-
 drivers/scsi/3w-.c | 7 ++-
 drivers/scsi/3w-.h | 7 ++-
 7 files changed, 15 insertions(+), 33 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index b3a7774..1b5ddd0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,7 +138,7 @@ S:  Maintained
 F: drivers/net/ethernet/3com/typhoon*

 3WARE SAS/SATA-RAID SCSI DRIVERS (3W-, 3W-9XXX, 3W-SAS)
-M: Adam Radford 
+M: Adam Radford 
 L: linux-scsi@vger.kernel.org
 W: http://www.lsi.com
 S: Supported
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index a56a7b2..316f87f 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -1,8 +1,8 @@
 /*
3w-9xxx.c -- 3ware 9000 Storage Controller device driver for Linux.

-   Written By: Adam Radford 
-   Modifications By: Tom Couch 
+   Written By: Adam Radford 
+   Modifications By: Tom Couch

Copyright (C) 2004-2009 Applied Micro Circuits Corporation.
Copyright (C) 2010 LSI Corporation.
@@ -41,10 +41,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Bugs/Comments/Suggestions should be mailed to:
-   linuxr...@lsi.com
-
-   For more information, goto:
-   http://www.lsi.com
+   aradf...@gmail.com

Note: This version of the driver does not contain a bundled firmware
  image.
diff --git a/drivers/scsi/3w-9xxx.h b/drivers/scsi/3w-9xxx.h
index 0fdc83c..b6c208c 100644
--- a/drivers/scsi/3w-9xxx.h
+++ b/drivers/scsi/3w-9xxx.h
@@ -1,8 +1,8 @@
 /*
3w-9xxx.h -- 3ware 9000 Storage Controller device driver for Linux.

-   Written By: Adam Radford 
-   Modifications By: Tom Couch 
+   Written By: Adam Radford 
+   Modifications By: Tom Couch

Copyright (C) 2004-2009 Applied Micro Circuits Corporation.
Copyright (C) 2010 LSI Corporation.
@@ -41,10 +41,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Bugs/Comments/Suggestions should be mailed to:
-   linuxr...@lsi.com
-
-   For more information, goto:
-   http://www.lsi.com
+   aradf...@gmail.com
 */

 #ifndef _3W_9XXX_H
diff --git a/drivers/scsi/3w-sas.c b/drivers/scsi/3w-sas.c
index f837485..970d8fa 100644
--- a/drivers/scsi/3w-sas.c
+++ b/drivers/scsi/3w-sas.c
@@ -1,7 +1,7 @@
 /*
3w-sas.c -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux.

-   Written By: Adam Radford 
+   Written By: Adam Radford 

Copyright (C) 2009 LSI Corporation.

@@ -43,10 +43,7 @@
LSI 3ware 9750 6Gb/s SAS/SATA-RAID

Bugs/Comments/Suggestions should be mailed to:
-   linuxr...@lsi.com
-
-   For more information, goto:
-   http://www.lsi.com
+   aradf...@gmail.com

History
---
diff --git a/drivers/scsi/3w-sas.h b/drivers/scsi/3w-sas.h
index fec6449..05e77d8 100644
--- a/drivers/scsi/3w-sas.h
+++ b/drivers/scsi/3w-sas.h
@@ -1,7 +1,7 @@
 /*
3w-sas.h -- LSI 3ware SAS/SATA-RAID Controller device driver for Linux.

-   Written By: Adam Radford 
+   Written By: Adam Radford 

Copyright (C) 2009 LSI Corporation.

@@ -39,10 +39,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Bugs/Comments/Suggestions should be mailed to:
-   linuxr...@lsi.com
-
-   For more information, goto:
-   http://www.lsi.com
+   aradf...@gmail.com
 */

 #ifndef _3W_SAS_H
diff --git a/drivers/scsi/3w-.c b/drivers/scsi/3w-.c
index 25aba16..26ab5c0 100644
--- a/drivers/scsi/3w-.c
+++ b/drivers/scsi/3w-.c
@@ -1,7 +1,7 @@
 /*
3w-.c -- 3ware Storage Controller device driver for Linux.

-   Written By: Adam Radford 
+   Written By: Adam Radford 
Modifications By: Joel Jacobson 
 Arnaldo Carvalho de Melo 
  Brad Strand 
@@ -47,10 +47,7 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Bugs/Comments/Suggestions should be mailed to:
-   linuxr...@lsi.com
-
-   For more information, goto:
-   http://www.lsi.com
+   aradf...@gmail.com

History
---
diff --git a/drivers/scsi/3w-.h b/drivers/scsi/3w-.h
index 6f65e66..c2575c0 100644
--- a/drivers/scsi/3w-.h
+++ b/drivers/scsi/3w-.h
@@ -1,7 +1,7 @@
 /*
3w-.h -- 3ware Storage Controller device driver for Linux.

-   Written By: Adam Radford 

[PATCH 3/3] zfcp: fix rport unblock race with LUN recovery

[Steffen Maier]

It is unavoidable that zfcp_scsi_queuecommand() has to finish
requests with DID_IMM_RETRY (like fc_remote_port_chkready())
during the time window when zfcp detected an unavailable rport but
fc_remote_port_delete(), which is asynchronous via
zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.

However, for the case when the rport becomes available again,
we should prevent unblocking the rport too early.
In contrast to other FCP LLDDs, zfcp has to open each LUN with the
FCP channel hardware before it can send I/O to a LUN.
So if a port already has LUNs attached and we unblock the rport just
after port recovery, recoveries of LUNs behind this port can still be
pending which in turn force zfcp_scsi_queuecommand() to unnecessarily
finish requests with DID_IMM_RETRY.

This also opens a time window with unblocked rport
(until the followup LUN reopen recovery has finished).
If a scsi_cmnd timeout occurs during this time window
fc_timed_out() cannot work as desired and such command
would indeed time out and trigger scsi_eh. This prevents
a clean and timely path failover.
This should not happen if the path issue can be recovered
on FC transport layer such as path issues involving RSCNs.

Fix this by only calling zfcp_scsi_schedule_rport_register(),
to asynchronously trigger fc_remote_port_add(),
after all LUN recoveries as children of the rport have finished
and no new recoveries of equal or higher order were triggered meanwhile.
Finished intentionally includes any recovery result no matter if
successful or failed (still unblock rport so other successful LUNs work).
For simplicity, we check after each finished LUN recovery if there
is another LUN recovery pending on the same port and then do nothing.
We handle the special case of a successful recovery of a port
without LUN children the same way without changing this case's semantics.

For debugging we introduce 2 new trace records written if the rport
unblock attempt was aborted due to still unfinished or freshly triggered
recovery. The records are only written above the default trace level.

Benjamin noticed the important special case of new recovery that can be
triggered between having given up the erp_lock and before calling
zfcp_erp_action_cleanup() within zfcp_erp_strategy().
We must avoid the following sequence:

ERP thread rport_work  other context
-  --  
port is unblocked, rport still blocked,
 due to pending/running ERP action,
 so ((port->status & ...UNBLOCK) != 0)
 and (port->rport == NULL)
unlock ERP
zfcp_erp_action_cleanup()
case ZFCP_ERP_ACTION_REOPEN_LUN:
zfcp_erp_try_rport_unblock()
((status & ...UNBLOCK) != 0) [OLD!]
   zfcp_erp_port_reopen()
   lock ERP
   zfcp_erp_port_block()
   port->status clear ...UNBLOCK
   unlock ERP
   zfcp_scsi_schedule_rport_block()
   port->rport_task = RPORT_DEL
   queue_work(rport_work)
   zfcp_scsi_rport_work()
   (port->rport_task != RPORT_ADD)
   port->rport_task = RPORT_NONE
   zfcp_scsi_rport_block()
   if (!port->rport) return
zfcp_scsi_schedule_rport_register()
port->rport_task = RPORT_ADD
queue_work(rport_work)
   zfcp_scsi_rport_work()
   (port->rport_task == RPORT_ADD)
   port->rport_task = RPORT_NONE
   zfcp_scsi_rport_register()
   (port->rport == NULL)
   rport = fc_remote_port_add()
   port->rport = rport;

Now the rport was erroneously unblocked while the zfcp_port is blocked.
This is another situation we want to avoid due to scsi_eh potential. This
state would at least remain until the new recovery from the other context
finished successfully, or potentially forever if it failed.
In order to close this race, we take the erp_lock inside
zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or LUN.
With that, the possible corresponding rport state sequences would be:
(unblock[ERP thread],block[other context]) if the ERP thread gets erp_lock
first and still sees ((port->status & ...UNBLOCK) != 0),
(block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
after the other context has already cleard ...UNBLOCK from port->status.

Since checking fields of struct erp_action is unsafe because they could
have been overwritten (re-used for new recovery) meanwhile, we only check
status of zfcp_port and LUN since these are only changed under erp_lock
elsewhere. Regarding the check of the 

[PATCH 2/3] zfcp: do not trace pure benign residual HBA responses at default level

[Steffen Maier]

Since quite a while, Linux issues enough SCSI commands per scsi_device
which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
and SAM_STAT_GOOD.
This floods the HBA trace area and we cannot see other and
important HBA trace records long enough.

Therefore, do not trace HBA response errors for pure
benign residual under counts at the default trace level.

This excludes benign residual under count combined with other
validity bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL.
For all those other cases, we still do want to see
both the HBA record and the corresponding SCSI record by default.

Signed-off-by: Steffen Maier 
Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA 
records.")
Cc:  #2.6.37+
Reviewed-by: Benjamin Block 
---
 drivers/s390/scsi/zfcp_dbf.h | 30 --
 drivers/s390/scsi/zfcp_fsf.h |  3 ++-
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_dbf.h b/drivers/s390/scsi/zfcp_dbf.h
index 2d06b5d2c05b..db186d44cfaf 100644
--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -2,7 +2,7 @@
  * zfcp device driver
  * debug feature declarations
  *
- * Copyright IBM Corp. 2008, 2015
+ * Copyright IBM Corp. 2008, 2016
  */
 
 #ifndef ZFCP_DBF_H
@@ -283,6 +283,30 @@ struct zfcp_dbf {
struct zfcp_dbf_scsiscsi_buf;
 };
 
+/**
+ * zfcp_dbf_hba_fsf_resp_suppress - true if we should not trace by default
+ * @req: request that has been completed
+ *
+ * Returns true if FCP response with only benign residual under count.
+ */
+static inline
+bool zfcp_dbf_hba_fsf_resp_suppress(struct zfcp_fsf_req *req)
+{
+   struct fsf_qtcb *qtcb = req->qtcb;
+   u32 fsf_stat = qtcb->header.fsf_status;
+   struct fcp_resp *fcp_rsp;
+   u8 rsp_flags, fr_status;
+
+   if (qtcb->prefix.qtcb_type != FSF_IO_COMMAND)
+   return false; /* not an FCP response */
+   fcp_rsp = (struct fcp_resp *)>bottom.io.fcp_rsp;
+   rsp_flags = fcp_rsp->fr_flags;
+   fr_status = fcp_rsp->fr_status;
+   return (fsf_stat == FSF_FCP_RSP_AVAILABLE) &&
+   (rsp_flags == FCP_RESID_UNDER) &&
+   (fr_status == SAM_STAT_GOOD);
+}
+
 static inline
 void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
 {
@@ -304,7 +328,9 @@ void zfcp_dbf_hba_fsf_response(struct zfcp_fsf_req *req)
zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);
 
} else if (qtcb->header.fsf_status != FSF_GOOD) {
-   zfcp_dbf_hba_fsf_resp("fs_ferr", 1, req);
+   zfcp_dbf_hba_fsf_resp("fs_ferr",
+ zfcp_dbf_hba_fsf_resp_suppress(req)
+ ? 5 : 1, req);
 
} else if ((req->fsf_command == FSF_QTCB_OPEN_PORT_WITH_DID) ||
   (req->fsf_command == FSF_QTCB_OPEN_LUN)) {
diff --git a/drivers/s390/scsi/zfcp_fsf.h b/drivers/s390/scsi/zfcp_fsf.h
index be1c04b334c5..ea3c76ac0de1 100644
--- a/drivers/s390/scsi/zfcp_fsf.h
+++ b/drivers/s390/scsi/zfcp_fsf.h
@@ -3,7 +3,7 @@
  *
  * Interface to the FSF support functions.
  *
- * Copyright IBM Corp. 2002, 2015
+ * Copyright IBM Corp. 2002, 2016
  */
 
 #ifndef FSF_H
@@ -78,6 +78,7 @@
 #define FSF_APP_TAG_CHECK_FAILURE  0x0082
 #define FSF_REF_TAG_CHECK_FAILURE  0x0083
 #define FSF_ADAPTER_STATUS_AVAILABLE   0x00AD
+#define FSF_FCP_RSP_AVAILABLE  0x00AF
 #define FSF_UNKNOWN_COMMAND0x00E2
 #define FSF_UNKNOWN_OP_SUBTYPE  0x00E3
 #define FSF_INVALID_COMMAND_OPTION  0x00E5
-- 
2.8.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

[PATCH 1/3] zfcp: fix use-after-"free" in FC ingress path after TMF

[Steffen Maier]

From: Benjamin Block 

When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
eh_target_reset_handler(), it expects us to relent the ownership over the
given scsi_cmnd and all other scsi_cmnds within the same scope - LUN or
target - when returning with SUCCESS from the callback ('release' them).
SCSI EH can then reuse those commands.

We did not follow this rule to release commands upon SUCCESS; and if
later a reply arrived for one of those supposed to be released commands,
we would still make use of the scsi_cmnd in our ingress tasklet. This
will at least result in undefined behavior or a kernel panic because of
a wrong kernel pointer dereference.

To fix this, we NULLify all pointers to scsi_cmnds
(struct zfcp_fsf_req *)->data in the matching scope if a TMF was
successful. This is done under the locks
(struct zfcp_adapter *)->abort_lock and (struct zfcp_reqlist *)->lock
to prevent the requests from being removed from the request-hashtable,
and the ingress tasklet from making use of the scsi_cmnd-pointer in
zfcp_fsf_fcp_cmnd_handler().

For cases where a reply arrives during SCSI EH, but before we get a
chance to NULLify the pointer - but before we return from the callback
-, we assume that the code is protected from races via the CAS operation
in blk_complete_request() that is called in scsi_done().

The following stacktrace shows an example for a crash resulting from the
previous behavior:

Unable to handle kernel pointer dereference at virtual kernel address 
fee17a672000
Oops: 0038 [#1] SMP
CPU: 2 PID: 0 Comm: swapper/2 Not tainted
task: 0003f7ff5be0 ti: 0003f3d38000 task.ti: 0003f3d38000
Krnl PSW : 0404d0018000 001156b0 (smp_vcpu_scheduled+0x18/0x40)
   R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
Krnl GPRS: 0020007e  fee17a671fd8 00030015
   8000 005dfde8 0703f7f80e00 4fa4e800
   00036ce8d8f8 00036ce8d9c0 0003ece8fe00 969c9e93
   0003fffd 00036ce8da10 003bf134 0003f3b07918
Krnl Code: 001156a2: a719lghi%r1,0
   001156a6: a7380015lhi%r3,21
  #001156aa: e3205008ag%r2,0(%r5)
  >001156b0: 482022b0lh%r2,688(%r2)
   001156b4: ae123000sigp%r1,%r2,0(%r3)
   001156b8: b2220020ipm%r2
   001156bc: 8820001csrl%r2,28
   001156c0: c0270001xilf%r2,1
Call Trace:
([<>] 0x0)
 [<03ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
 [<03ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
 [<03ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
 [<03ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
 [<03ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
 [<03ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
 [<00141fd4>] tasklet_action+0x9c/0x170
 [<00141550>] __do_softirq+0xe8/0x258
 [<0010ce0a>] do_softirq+0xba/0xc0
 [<0014187c>] irq_exit+0xc4/0xe8
 [<0046b526>] do_IRQ+0x146/0x1d8
 [<005d6a3c>] io_return+0x0/0x8
 [<005d6422>] vtime_stop_cpu+0x4a/0xa0
([<>] 0x0)
 [<00103d8a>] arch_cpu_idle+0xa2/0xb0
 [<00197f94>] cpu_startup_entry+0x13c/0x1f8
 [<00114782>] smp_start_secondary+0xda/0xe8
 [<005d6efe>] restart_int_handler+0x56/0x6c
 [<>] 0x0
Last Breaking-Event-Address:
 [<003bf12e>] arch_spin_lock_wait+0x56/0xb0

Suggested-by: Steffen Maier 
Signed-off-by: Benjamin Block 
Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
Cc:  #2.6.32+
Signed-off-by: Steffen Maier 
---
 drivers/s390/scsi/zfcp_dbf.h | 11 
 drivers/s390/scsi/zfcp_reqlist.h | 30 -
 drivers/s390/scsi/zfcp_scsi.c| 57 ++--
 3 files changed, 95 insertions(+), 3 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_dbf.h b/drivers/s390/scsi/zfcp_dbf.h
index 36d07584271d..2d06b5d2c05b 100644
--- a/drivers/s390/scsi/zfcp_dbf.h
+++ b/drivers/s390/scsi/zfcp_dbf.h
@@ -388,4 +388,15 @@ void zfcp_dbf_scsi_devreset(char *tag, struct scsi_cmnd 
*scmnd, u8 flag)
_zfcp_dbf_scsi(tmp_tag, 1, scmnd, NULL);
 }
 
+/**
+ * zfcp_dbf_scsi_nullcmnd() - trace NULLify of SCSI command in dev/tgt-reset.
+ * @scmnd: SCSI command that was NULLified.
+ * @fsf_req: request that owned @scmnd.
+ */
+static inline void zfcp_dbf_scsi_nullcmnd(struct scsi_cmnd *scmnd,
+ struct zfcp_fsf_req *fsf_req)
+{
+   _zfcp_dbf_scsi("scfc__1", 3, scmnd, fsf_req);
+}
+
 #endif /* ZFCP_DBF_H */
diff --git a/drivers/s390/scsi/zfcp_reqlist.h 

[PATCH 0/3] zfcp fixes

[Steffen Maier]

Hi all,

here is a series of important zfcp fixes all marked for stable.
They apply to the fixes branch of James' scsi.git or to v4.9-rc8.

Patch 1 is the most important one since it fixes a panic
that can occur under certain circumstances.

Benjamin Block (1):
  zfcp: fix use-after-"free" in FC ingress path after TMF

Steffen Maier (2):
  zfcp: do not trace pure benign residual HBA responses at default level
  zfcp: fix rport unblock race with LUN recovery

 drivers/s390/scsi/zfcp_dbf.c | 17 +--
 drivers/s390/scsi/zfcp_dbf.h | 41 +--
 drivers/s390/scsi/zfcp_erp.c | 61 ++--
 drivers/s390/scsi/zfcp_ext.h |  4 ++-
 drivers/s390/scsi/zfcp_fsf.h |  3 +-
 drivers/s390/scsi/zfcp_reqlist.h | 30 +++-
 drivers/s390/scsi/zfcp_scsi.c| 61 
 7 files changed, 202 insertions(+), 15 deletions(-)

-- 
2.8.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: [PATCH v2] scsi: avoid a permanent stop of the scsi device's request queue

[James Bottomley]

On Fri, 2016-12-09 at 17:35 +0800, Wei Fang wrote:
> A scan work can run simultaneously with fc_remote_port_delete().
> If a scsi device is added to the ->__devices list in the scan work,
> it can be touched and will be blocked in scsi_target_block(), which
> will be called in fc_remote_port_delete(), and QUEUE_FLAG_STOPPED
> flag will be setted to the scsi device's request queue.
>  
> The scsi device is being setted to the SDEV_RUNNING state in
> scsi_sysfs_add_sdev() at the end of the scan work. When the remote
> port reappears, scsi_target_unblock() will be called, but the
> QUEUE_FLAG_STOPPED flag will not be cleared, since
> scsi_internal_device_unblock() ignores SCSI devices in SDEV_RUNNING
> state. It results in a permanent stop of the scsi device's request
> queue. Every requests sended to it will be blocked.

This is a bit unclear as a description of the problem

> Since the scsi device shouldn't be unblocked in this case, fix
> it by removing scsi_device_set_state() in scsi_sysfs_add_sdev().

So is this as a description of the solution, because the reader doesn't
know there's a prior place where SDEV_RUNNING was previously set.

How about

---
A race between scanning and fc_remote_port_delete() may result in a
permanent stop if the device gets blocked before scsi_sysfs_add_lun()
and unblocked after.  The reason is that blocking a device sets both
the SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED.  However,
scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes
the device to be ignored by scsi_target_unblock() and thus never have
its QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
running but has a stopped queue.

We actually have two places where SDEV_RUNNING is set: once in
scsi_add_lun() which respects the blocked flag and once in
scsi_sysfs_add_sdev() which doesn't.  Since the second set is entirely
spurious, simply remove it to fix the problem.
---

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: [PATCH] scsi: hpsa: remove memory allocate failure message

[Don Brace]

> -Original Message-
> From: kushwah...@samsung.com [mailto:kushwah...@samsung.com]
> Sent: Friday, December 09, 2016 5:18 AM
> To: Don Brace; jbottom...@odin.com
> Cc: linux-scsi@vger.kernel.org; kushwah...@samsung.com;
> d.wadha...@samsung.com
> Subject: [PATCH] scsi: hpsa: remove memory allocate failure message
> 
> EXTERNAL EMAIL
> 
> 
> From: Amit Kushwaha 
> 
> This patch cleanup warning reported by checkpatch.pl
> WARNING: Possible unnecessary 'out of memory' message
> With no available memory, a warn on message already gets printed
> by page alloc apis
> 
> Signed-off-by: Amit Kushwaha 

I notice that checkpatch reports other similar messages when run 
against the entire driver, which driver version did you run
checkpatch on?

Thanks,
Don

> ---
>  drivers/scsi/hpsa.c |   21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
> index 40669f8..bf14405 100644
> --- a/drivers/scsi/hpsa.c
> +++ b/drivers/scsi/hpsa.c
> @@ -1455,10 +1455,9 @@ static void hpsa_monitor_offline_device(struct
> ctlr_info *h,
> 
> /* Device is not on the list, add it. */
> device = kmalloc(sizeof(*device), GFP_KERNEL);
> -   if (!device) {
> -   dev_warn(>pdev->dev, "out of memory in %s\n", __func__);
> +   if (!device)
> return;
> -   }
> +
> memcpy(device->scsi3addr, scsi3addr, sizeof(device->scsi3addr));
> spin_lock_irqsave(>offline_device_lock, flags);
> list_add_tail(>offline_list, >offline_device_list);
> @@ -1928,17 +1927,15 @@ static int hpsa_alloc_sg_chain_blocks(struct
> ctlr_info *h)
> 
> h->cmd_sg_list = kzalloc(sizeof(*h->cmd_sg_list) * h->nr_cmds,
> GFP_KERNEL);
> -   if (!h->cmd_sg_list) {
> -   dev_err(>pdev->dev, "Failed to allocate SG list\n");
> +   if (!h->cmd_sg_list)
> return -ENOMEM;
> -   }
> +
> for (i = 0; i < h->nr_cmds; i++) {
> h->cmd_sg_list[i] = kmalloc(sizeof(*h->cmd_sg_list[i]) *
> h->chainsize, GFP_KERNEL);
> -   if (!h->cmd_sg_list[i]) {
> -   dev_err(>pdev->dev, "Failed to allocate cmd SG\n");
> +   if (!h->cmd_sg_list[i])
> goto clean;
> -   }
> +
> }
> return 0;
> 
> @@ -3759,11 +3756,9 @@ static void hpsa_update_scsi_devices(struct
> ctlr_info *h, int hostno)
> }
> 
> currentsd[i] = kzalloc(sizeof(*currentsd[i]), GFP_KERNEL);
> -   if (!currentsd[i]) {
> -   dev_warn(>pdev->dev, "out of memory at %s:%d\n",
> -   __FILE__, __LINE__);
> +   if (!currentsd[i])
> goto out;
> -   }
> +
> ndev_allocated++;
> }
> 
> --
> 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: [PATCH v2] scsi: avoid a permanent stop of the scsi device's request queue

[James Bottomley]

On Fri, 2016-12-09 at 17:35 +0800, Wei Fang wrote:

> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 8990e58..5c53cf5 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -31,7 +31,7 @@ struct scsi_mode_data {
>  enum scsi_device_state {
>   SDEV_CREATED = 1,   /* device created but not added to
> sysfs
>* Only internal commands allowed
> (for inq) */
> - SDEV_RUNNING,   /* device properly configured
> + SDEV_RUNNING,   /* device properly initialized
>* All commands allowed */
>   SDEV_CANCEL,/* beginning to delete device
>* Only error handler commands
> allowed */

This hunk is still pointless.  What even is the difference between
initialized and configured to someone reading the comments?

The reason for not having pointless changes is to make this as clean as
possible for a backport to stable.

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: [PATCH] linux/types.h: enable endian checks for all sparse builds

[Bart Van Assche]

On 12/08/16 22:40, Madhani, Himanshu wrote:
> We’ll take a look and send patches to resolve these warnings.

Thanks!

Bart.

--
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] qla2xxx/qla4xxx: use kobj_to_dev

[Geliang Tang]

Use kobj_to_dev() instead of open-coding it.

Signed-off-by: Geliang Tang 
---
 drivers/scsi/qla2xxx/qla_attr.c | 42 ++---
 drivers/scsi/qla4xxx/ql4_attr.c |  6 ++
 2 files changed, 16 insertions(+), 32 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
index fe7469c..820b416 100644
--- a/drivers/scsi/qla2xxx/qla_attr.c
+++ b/drivers/scsi/qla2xxx/qla_attr.c
@@ -21,8 +21,7 @@ qla2x00_sysfs_read_fw_dump(struct file *filp, struct kobject 
*kobj,
   struct bin_attribute *bin_attr,
   char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
int rval = 0;
 
@@ -54,8 +53,7 @@ qla2x00_sysfs_write_fw_dump(struct file *filp, struct kobject 
*kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
int reading;
 
@@ -151,8 +149,7 @@ qla2x00_sysfs_read_nvram(struct file *filp, struct kobject 
*kobj,
 struct bin_attribute *bin_attr,
 char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
 
if (!capable(CAP_SYS_ADMIN))
@@ -170,8 +167,7 @@ qla2x00_sysfs_write_nvram(struct file *filp, struct kobject 
*kobj,
  struct bin_attribute *bin_attr,
  char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
uint16_tcnt;
 
@@ -238,8 +234,7 @@ qla2x00_sysfs_read_optrom(struct file *filp, struct kobject 
*kobj,
  struct bin_attribute *bin_attr,
  char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
ssize_t rval = 0;
 
@@ -259,8 +254,7 @@ qla2x00_sysfs_write_optrom(struct file *filp, struct 
kobject *kobj,
   struct bin_attribute *bin_attr,
   char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
 
if (ha->optrom_state != QLA_SWRITING)
@@ -292,8 +286,7 @@ qla2x00_sysfs_write_optrom_ctl(struct file *filp, struct 
kobject *kobj,
   struct bin_attribute *bin_attr,
   char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
uint32_t start = 0;
uint32_t size = ha->optrom_size;
@@ -473,8 +466,7 @@ qla2x00_sysfs_read_vpd(struct file *filp, struct kobject 
*kobj,
   struct bin_attribute *bin_attr,
   char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
uint32_t faddr;
 
@@ -502,8 +494,7 @@ qla2x00_sysfs_write_vpd(struct file *filp, struct kobject 
*kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
 {
-   struct scsi_qla_host *vha = shost_priv(dev_to_shost(container_of(kobj,
-   struct device, kobj)));
+   struct scsi_qla_host *vha = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qla_hw_data *ha = vha->hw;
uint8_t *tmp_data;
 
@@ -555,8 +546,7 @@ qla2x00_sysfs_read_sfp(struct file *filp, struct kobject 
*kobj,
   struct bin_attribute *bin_attr,
  

[LSF/MM TOPIC] [LSF/MM ATTEND] XCOPY

[Ewan D. Milne]

I'd like to attend LSF/MM this year, and I'd like to discuss
XCOPY and what we need to do to get this functionality
incorporated.  Martin/Mikulas' patches have been around for
a while, I think the last holdup was some request flag changes
that have since been resolved.

We do need to have a token-based XCOPY implementation as that
is what the array vendors are supporting.

-Ewan


--
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 V4 11/11] megaraid_sas: driver version upgrade

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Upgrade driver version.
>
> This patch is depending on patch 10
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 7334e07..310555a 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -35,8 +35,8 @@
>  /*
>   * MegaRAID SAS Driver meta data
>   */
> -#define MEGASAS_VERSION  "06.812.07.00-rc1"
> -#define MEGASAS_RELDATE  "August 22, 2016"
> +#define MEGASAS_VERSION  "07.700.00.00-rc1"
> +#define MEGASAS_RELDATE  "November 29, 2016"
>  
>  /*
>   * Device IDs

Reviewed-by: Tomas Henzl 

Tomas

--
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 V4 10/11] megaraid_sas: Implement the PD Map support for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Update Linux driver to use new pdTargetId field for JBOD target ID
>
> This patch is depending on patch 9
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

--
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 V4 09/11] megaraid_sas: ldio_outstanding variable is not decremented in completion path

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> ldio outstanding variable needs to be decremented in io completion path for
> iMR dual queue depth
>
> This patch is depending on patch 8
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

--
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 V4 08/11] megaraid_sas: Enable or Disable Fast path based on the PCI Threshold Bandwidth

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> Large SEQ IO workload should sent as non fast path commands
>
> This patch is depending on patch 7
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|  8 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 48 
> +
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 11 +--
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 20 +++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  2 +-
>  5 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index 3e087ab..eb5be2b 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1429,6 +1429,8 @@ enum FW_BOOT_CONTEXT {
>  #define MFI_1068_FW_HANDSHAKE_OFFSET 0x64
>  #define MFI_1068_FW_READY0x
>  
> +#define MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL HZ
> +
>  #define MR_MAX_REPLY_QUEUES_OFFSET  0X001F
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET  0X003FC000
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
> @@ -2101,6 +2103,10 @@ struct megasas_instance {
>   atomic_t ldio_outstanding;
>   atomic_t fw_reset_no_pci_access;
>  
> + atomic64_t bytes_wrote; /* used for raid1 fast path enable or disable */
> + atomic_t r1_write_fp_capable;

Is a an atomic variable needed for a just boolean variable?

> +
> +
>   struct megasas_instance_template *instancet;
>   struct tasklet_struct isr_tasklet;
>   struct work_struct work_init;
> @@ -2143,6 +2149,7 @@ struct megasas_instance {
>   long reset_flags;
>   struct mutex reset_mutex;
>   struct timer_list sriov_heartbeat_timer;
> + struct timer_list r1_fp_hold_timer;
>   char skip_heartbeat_timer_del;
>   u8 requestorId;
>   char PlasmaFW111;
> @@ -2159,6 +2166,7 @@ struct megasas_instance {
>   bool is_ventura;
>   bool msix_combined;
>   u16 max_raid_mapsize;
> + u64 pci_threshold_bandwidth; /* used to control the fp writes */
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 8aafb59..899d25c 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -1940,6 +1940,9 @@ void megaraid_sas_kill_hba(struct megasas_instance 
> *instance)
>   }
>   /* Complete outstanding ioctls when adapter is killed */
>   megasas_complete_outstanding_ioctls(instance);
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>  }
>  
>   /**
> @@ -2438,6 +2441,24 @@ void megasas_sriov_heartbeat_handler(unsigned long 
> instance_addr)
>   }
>  }
>  
> +/*Handler for disabling/enabling raid 1 fast paths*/
> +void megasas_change_r1_fp_status(unsigned long instance_addr)
> +{
> + struct megasas_instance *instance =
> + (struct megasas_instance *)instance_addr;
> + if (atomic64_read(>bytes_wrote) >=
> + instance->pci_threshold_bandwidth) {
> +
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 0);
> + } else {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + }
> + mod_timer(>r1_fp_hold_timer,
> +  jiffies + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> +}
> +
>  /**
>   * megasas_wait_for_outstanding -Wait for all outstanding cmds
>   * @instance:Adapter soft state
> @@ -5371,6 +5392,17 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>   instance->skip_heartbeat_timer_del = 1;
>   }
>  
> + if (instance->is_ventura) {
> + atomic64_set(>bytes_wrote, 0);
> + atomic_set(>r1_write_fp_capable, 1);
> + megasas_start_timer(instance,
> + >r1_fp_hold_timer,
> + megasas_change_r1_fp_status,
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + dev_info(>pdev->dev, "starting the 
> raid 1 fp timer with interval %d\n",
> + MEGASAS_RAID1_FAST_PATH_STATUS_CHECK_INTERVAL);
> + }
> +
>   return 0;
>  
>  fail_get_ld_pd_list:
> @@ -6161,6 +6193,9 @@ static void megasas_shutdown_controller(struct 
> megasas_instance *instance,
>   if (instance->requestorId && !instance->skip_heartbeat_timer_del)
>   del_timer_sync(>sriov_heartbeat_timer);
>  
> + if (instance->is_ventura)
> + del_timer_sync(>r1_fp_hold_timer);
> +
>   megasas_flush_cache(instance);
>   megasas_shutdown_controller(instance, MR_DCMD_HIBERNATE_SHUTDOWN);
>  
> @@ -6280,6 +6315,16 @@ 

Re: [PATCH V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas_base.c   | 53 
> ++---
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 19 ++-
>  drivers/scsi/megaraid/megaraid_sas_fusion.h |  1 +
>  3 files changed, 37 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index 3f06b57..8aafb59 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -5057,34 +5057,29 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  
>   reg_set = instance->reg_set;
>  
> - switch (instance->pdev->device) {
> - case PCI_DEVICE_ID_LSI_FUSION:
> - case PCI_DEVICE_ID_LSI_PLASMA:
> - case PCI_DEVICE_ID_LSI_INVADER:
> - case PCI_DEVICE_ID_LSI_FURY:
> - case PCI_DEVICE_ID_LSI_INTRUDER:
> - case PCI_DEVICE_ID_LSI_INTRUDER_24:
> - case PCI_DEVICE_ID_LSI_CUTLASS_52:
> - case PCI_DEVICE_ID_LSI_CUTLASS_53:
> + if (fusion)
>   instance->instancet = _instance_template_fusion;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078R:
> - case PCI_DEVICE_ID_LSI_SAS1078DE:
> - instance->instancet = _instance_template_ppc;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> - case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> - instance->instancet = _instance_template_gen2;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> - case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> - instance->instancet = _instance_template_skinny;
> - break;
> - case PCI_DEVICE_ID_LSI_SAS1064R:
> - case PCI_DEVICE_ID_DELL_PERC5:
> - default:
> - instance->instancet = _instance_template_xscale;
> - break;
> + else {
> + switch (instance->pdev->device) {
> + case PCI_DEVICE_ID_LSI_SAS1078R:
> + case PCI_DEVICE_ID_LSI_SAS1078DE:
> + instance->instancet = _instance_template_ppc;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1078GEN2:
> + case PCI_DEVICE_ID_LSI_SAS0079GEN2:
> + instance->instancet = _instance_template_gen2;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS0073SKINNY:
> + case PCI_DEVICE_ID_LSI_SAS0071SKINNY:
> + instance->instancet = _instance_template_skinny;
> + break;
> + case PCI_DEVICE_ID_LSI_SAS1064R:
> + case PCI_DEVICE_ID_DELL_PERC5:
> + default:
> + instance->instancet = _instance_template_xscale;
> + instance->pd_list_not_supported = 1;
> + break;
> + }
>   }
>  
>   if (megasas_transition_to_ready(instance, 0)) {
> @@ -5828,7 +5823,9 @@ static int megasas_probe_one(struct pci_dev *pdev,
>   if ((instance->pdev->device == PCI_DEVICE_ID_LSI_FUSION) ||
>   (instance->pdev->device == PCI_DEVICE_ID_LSI_PLASMA))
>   fusion->adapter_type = THUNDERBOLT_SERIES;
> - else if (!instance->is_ventura)
> + else if (instance->is_ventura)
> + fusion->adapter_type = VENTURA_SERIES;
> + else
>   fusion->adapter_type = INVADER_SERIES;
>   }
>   break;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 58f86aa..f968a23 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -244,7 +244,10 @@ inline void megasas_return_cmd_fusion(struct 
> megasas_instance *instance,
>  
>   reg_set = instance->reg_set;
>  
> - cur_max_fw_cmds = readl(>reg_set->outbound_scratch_pad_3) & 
> 0x00;
> + /* ventura FW does not fill outbound_scratch_pad_3 with queue depth */
> + if (!instance->is_ventura)
> + cur_max_fw_cmds =
> + readl(>reg_set->outbound_scratch_pad_3) & 0x00;
>  
>   if (dual_qdepth_disable || !cur_max_fw_cmds)

This test connected with the fact that ventura skips reading cur_max_fw_cmds
makes using ventura equal to "dual_qdepth_disable == 1" so ldio_threshold is 
not set.
Is that intentional?

tomash 

>   cur_max_fw_cmds = 
> instance->instancet->read_fw_status_reg(reg_set) & 0x00;
> @@ -843,7 +846,7 @@ static int megasas_create_sg_sense_fusion(struct 
> megasas_instance *instance)
>   drv_ops = (MFI_CAPABILITIES *) &(init_frame->driver_operations);
>  
>   /* driver support Extended MSIX */
> - if (fusion->adapter_type 

Re: [PATCH v4 5/6] qla2xxx: Add Block Multi Queue functionality.

[Christoph Hellwig]

This also need to write up the ->map_queues callback so that the MSI-X
assignment is preserved.
--
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 v4 4/6] qla2xxx: Add multiple queue pair functionality.

[Christoph Hellwig]

Ok.  We'll still need to use PCI_IRQ_AFFINITY here after it's removed
i nthe previous patch, but with pci_irq_alloc_vectors_affinity so that
we can get the separate non-assignment vector right as in the previous
discussion.
--
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 V4 07/11] megaraid_sas: Add the Support for SAS3.5 Generic Megaraid Controllers Capabilities

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> The Megaraid driver has to support the SAS3.5 Generic Megaraid Controllers 
> Firmware functionality.
>
> This patch is depending on patch 6
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

--
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 V4 06/11] megaraid_sas: Dynamic Raid Map Changes for SAS3.5 Generic Megaraid Controllers

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> SAS3.5 Generic Megaraid Controllers FW will support new dynamic RaidMap to 
> have different
> sizes for different number of supported VDs.
>
> This patch is depending on patch 5
>
> Signed-off-by: Sasikumar Chandrasekaran 
> ---
>  drivers/scsi/megaraid/megaraid_sas.h|   7 +
>  drivers/scsi/megaraid/megaraid_sas_base.c   |  61 --
>  drivers/scsi/megaraid/megaraid_sas_fp.c | 303 
> 
>  drivers/scsi/megaraid/megaraid_sas_fusion.c | 223 
>  drivers/scsi/megaraid/megaraid_sas_fusion.h | 240 ++
>  5 files changed, 699 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
> b/drivers/scsi/megaraid/megaraid_sas.h
> index f4d6a94..3e087ab 100644
> --- a/drivers/scsi/megaraid/megaraid_sas.h
> +++ b/drivers/scsi/megaraid/megaraid_sas.h
> @@ -1434,6 +1434,12 @@ enum FW_BOOT_CONTEXT {
>  #define MR_MAX_REPLY_QUEUES_EXT_OFFSET_SHIFT14
>  #define MR_MAX_MSIX_REG_ARRAY   16
>  #define MR_RDPQ_MODE_OFFSET  0X0080
> +
> +#define MR_MAX_RAID_MAP_SIZE_OFFSET_SHIFT16
> +#define MR_MAX_RAID_MAP_SIZE_MASK0x1FF
> +#define MR_MIN_MAP_SIZE  0x1
> +/* 64k */
> +
>  #define MR_CAN_HANDLE_SYNC_CACHE_OFFSET  0X0100
>  
>  /*
> @@ -2152,6 +2158,7 @@ struct megasas_instance {
>   bool fw_sync_cache_support;
>   bool is_ventura;
>   bool msix_combined;
> + u16 max_raid_mapsize;
>  };
>  struct MR_LD_VF_MAP {
>   u32 size;
> diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
> b/drivers/scsi/megaraid/megaraid_sas_base.c
> index c52f7be..3f06b57 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_base.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_base.c
> @@ -4424,8 +4424,7 @@ int megasas_alloc_cmds(struct megasas_instance 
> *instance)
>  static void megasas_update_ext_vd_details(struct megasas_instance *instance)
>  {
>   struct fusion_context *fusion;
> - u32 old_map_sz;
> - u32 new_map_sz;
> + u32 ventura_map_sz = 0;
>  
>   fusion = instance->ctrl_context;
>   /* For MFI based controllers return dummy success */
> @@ -4455,21 +4454,39 @@ static void megasas_update_ext_vd_details(struct 
> megasas_instance *instance)
>   instance->supportmax256vd ? "Extended VD(240 VD)firmware" :
>   "Legacy(64 VD) firmware");
>  
> - old_map_sz = sizeof(struct MR_FW_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->fw_supported_vd_count - 1));
> - new_map_sz = sizeof(struct MR_FW_RAID_MAP_EXT);
> - fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP) +
> - (sizeof(struct MR_LD_SPAN_MAP) *
> - (instance->drv_supported_vd_count - 1));
> -
> - fusion->max_map_sz = max(old_map_sz, new_map_sz);
> + if (instance->max_raid_mapsize) {
> + ventura_map_sz = instance->max_raid_mapsize *
> + MR_MIN_MAP_SIZE; /* 64k */
> + fusion->current_map_sz = ventura_map_sz;
> + fusion->max_map_sz = ventura_map_sz;
> + } else {
> + fusion->old_map_sz =  sizeof(struct MR_FW_RAID_MAP) +
> + (sizeof(struct MR_LD_SPAN_MAP) *
> + (instance->fw_supported_vd_count - 1));
> + fusion->new_map_sz =  sizeof(struct MR_FW_RAID_MAP_EXT);
>  
> + fusion->max_map_sz =
> + max(fusion->old_map_sz, fusion->new_map_sz);
>  
> - if (instance->supportmax256vd)
> - fusion->current_map_sz = new_map_sz;
> - else
> - fusion->current_map_sz = old_map_sz;
> + if (instance->supportmax256vd)
> + fusion->current_map_sz = fusion->new_map_sz;
> + else
> + fusion->current_map_sz = fusion->old_map_sz;
> + }
> + /* irrespective of FW raid maps, driver raid map is constant */
> + fusion->drv_map_sz = sizeof(struct MR_DRV_RAID_MAP_ALL);
> +#if VD_EXT_DEBUG
> + dev_info(>pdev->dev, "instance->max_raid_mapsize 0x%x \n ",
> + instance->max_raid_mapsize);
> + dev_info(>pdev->dev,
> + "new_map_sz = 0x%x, old_map_sz = 0x%x, "
> + "ventura_map_sz = 0x%x, current_map_sz = 0x%x "
> + "fusion->drv_map_sz =0x%x, size of driver raid map 0x%lx\n",
> + fusion->new_map_sz, fusion->old_map_sz,
> + ventura_map_sz, fusion->current_map_sz,
> + fusion->drv_map_sz,
> + sizeof(struct MR_DRV_RAID_MAP_ALL));
> +#endif
>  }
>  
>  /**
> @@ -5010,7 +5027,7 @@ static int megasas_init_fw(struct megasas_instance 
> *instance)
>  {
>   u32 max_sectors_1;
>   u32 max_sectors_2;
> - u32 tmp_sectors, msix_enable, scratch_pad_2;
> + u32 tmp_sectors, 

Re: [PREEMPT-RT] bnx2i + bnx2fc: convert to generic workqueue (#2)

[Johannes Thumshirn]

[ +Lee and Chris ]
On Fri, Dec 09, 2016 at 12:33:11PM +0100, Thomas Gleixner wrote:
> On Tue, 29 Nov 2016, Martin K. Petersen wrote:
> 
> > > "Sebastian" == Sebastian Andrzej Siewior  
> > > writes:
> > 
> > Sebastian> This is the a repost + fixups to get the patches applied
> > Sebastian> against v4.9-rc4.  mkp's scsi for-next tree can be merged
> > Sebastian> with no conflicts.
> > 
> > Chad?
> 
> Polite ping on this. We really want to get rid of the hotplug notifier crap
> in 4.10. This one of the last holdouts.

As I already said, the FCoE part looks OK and is tested.

Lee, Chris can you do some testing with the iSCSI part as well, seems like
Chad isn't reachable.

Thanks, 
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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: [PREEMPT-RT] bnx2i + bnx2fc: convert to generic workqueue (#2)

[Thomas Gleixner]

On Tue, 29 Nov 2016, Martin K. Petersen wrote:

> > "Sebastian" == Sebastian Andrzej Siewior  writes:
> 
> Sebastian> This is the a repost + fixups to get the patches applied
> Sebastian> against v4.9-rc4.  mkp's scsi for-next tree can be merged
> Sebastian> with no conflicts.
> 
> Chad?

Polite ping on this. We really want to get rid of the hotplug notifier crap
in 4.10. This one of the last holdouts.

Thanks,

tglx
--
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: hpsa: remove memory allocate failure message

[kushwaha . a]

From: Amit Kushwaha 

This patch cleanup warning reported by checkpatch.pl
WARNING: Possible unnecessary 'out of memory' message
With no available memory, a warn on message already gets printed
by page alloc apis

Signed-off-by: Amit Kushwaha 
---
 drivers/scsi/hpsa.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 40669f8..bf14405 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -1455,10 +1455,9 @@ static void hpsa_monitor_offline_device(struct ctlr_info 
*h,
 
/* Device is not on the list, add it. */
device = kmalloc(sizeof(*device), GFP_KERNEL);
-   if (!device) {
-   dev_warn(>pdev->dev, "out of memory in %s\n", __func__);
+   if (!device)
return;
-   }
+
memcpy(device->scsi3addr, scsi3addr, sizeof(device->scsi3addr));
spin_lock_irqsave(>offline_device_lock, flags);
list_add_tail(>offline_list, >offline_device_list);
@@ -1928,17 +1927,15 @@ static int hpsa_alloc_sg_chain_blocks(struct ctlr_info 
*h)
 
h->cmd_sg_list = kzalloc(sizeof(*h->cmd_sg_list) * h->nr_cmds,
GFP_KERNEL);
-   if (!h->cmd_sg_list) {
-   dev_err(>pdev->dev, "Failed to allocate SG list\n");
+   if (!h->cmd_sg_list)
return -ENOMEM;
-   }
+
for (i = 0; i < h->nr_cmds; i++) {
h->cmd_sg_list[i] = kmalloc(sizeof(*h->cmd_sg_list[i]) *
h->chainsize, GFP_KERNEL);
-   if (!h->cmd_sg_list[i]) {
-   dev_err(>pdev->dev, "Failed to allocate cmd SG\n");
+   if (!h->cmd_sg_list[i])
goto clean;
-   }
+
}
return 0;
 
@@ -3759,11 +3756,9 @@ static void hpsa_update_scsi_devices(struct ctlr_info 
*h, int hostno)
}
 
currentsd[i] = kzalloc(sizeof(*currentsd[i]), GFP_KERNEL);
-   if (!currentsd[i]) {
-   dev_warn(>pdev->dev, "out of memory at %s:%d\n",
-   __FILE__, __LINE__);
+   if (!currentsd[i])
goto out;
-   }
+
ndev_allocated++;
}
 
-- 
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: [PATCH V4 05/11] megaraid_sas: SAS3.5 Generic Megaraid Controllers Fast Path for RAID 1/10 Writes

[Tomas Henzl]

On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> To improve RAID 1/10 Write performance, OS drivers need to issue the required 
> Write
> IOs as Fast Path IOs (after the appropriate checks allowing Fast Path to be 
> used)
> to the appropriate physical drives (translated from the OS logical IO) and 
> wait for
> all Write IOs to complete.  If any of the Write IOs fail or time out, the IO 
> will be
> re issued to FW as an LD IO so FW can perform the error handling.
>
> This patch is depending on patch 4
>
> Signed-off-by: Sasikumar Chandrasekaran 

Reviewed-by: Tomas Henzl 

Tomas

--
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 v2] xen/scsifront: don't request a slot on the ring until request is ready

[Juergen Gross]

On 02/12/16 07:15, Juergen Gross wrote:
> Instead of requesting a new slot on the ring to the backend early, do
> so only after all has been setup for the request to be sent. This
> makes error handling easier as we don't need to undo the request id
> allocation and ring slot allocation.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Juergen Gross 


Commited to xen/tip.git for-linus-4.10


Juergen
--
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 v2] lpfc: Fix possible NULL pointer dereference

[Johannes Thumshirn]

On Thu, Dec 08, 2016 at 11:01:30AM -0800, James Bottomley wrote:
> On Tue, 2016-08-02 at 01:17 -0400, Martin K. Petersen wrote:
> > > > > > > "Johannes" == Johannes Thumshirn 
> > > > > > > writes:
> > 
> > Johannes> Check for the existence of piocb->vport before accessing
> > it.
> > 
> > Applied to 4.8/scsi-queue.
> 
> OK, now that this has caused problems, could learn the lessons from it?
> 
> Lines like this:
> 
> +   BUG_ON(!piocb || !piocb->vport);
> 
> Should never appear in code.  They only have the potential to cause
> problems if the condition is inexact and they provide precisely no
> information over what a NULL deref in the kernel is going to tell us
> anyway ... this one even obscures information because you don't know if
> pciob was null or pciob->vport when it triggers.
> 
> The rule is never BUG_ON a NULL pointer unless you have an extremely
> good reason why the kernel NULL deref handler isn't adequate (which
> should be documented in the commit log).

Yup I fully agree, but shouldn't we take as a 2nd lesson that BUG_ON()s
generally aren't an extremely good idea? I personally think a lot of
BUG_ON()s in driver code can be eliminated with proper error handling.

That said, mea culpa.

Byte,
Johannes

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
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 v2] scsi: avoid a permanent stop of the scsi device's request queue

[Wei Fang]

A scan work can run simultaneously with fc_remote_port_delete().
If a scsi device is added to the ->__devices list in the scan work,
it can be touched and will be blocked in scsi_target_block(), which
will be called in fc_remote_port_delete(), and QUEUE_FLAG_STOPPED
flag will be setted to the scsi device's request queue.

The scsi device is being setted to the SDEV_RUNNING state in
scsi_sysfs_add_sdev() at the end of the scan work. When the remote
port reappears, scsi_target_unblock() will be called, but the
QUEUE_FLAG_STOPPED flag will not be cleared, since
scsi_internal_device_unblock() ignores SCSI devices in SDEV_RUNNING
state. It results in a permanent stop of the scsi device's request
queue. Every requests sended to it will be blocked.

Since the scsi device shouldn't be unblocked in this case, fix
it by removing scsi_device_set_state() in scsi_sysfs_add_sdev().

Reported-and-tested-by: Zengxi Chen 
Signed-off-by: Wei Fang 
---
Changes v1->v2:
- don't modify scsi_internal_device_unblock(), just remove changing
  state to SDEV_RUNNING in scsi_sysfs_add_sdev(), suggested by
  James Bottomley and Ewan D. Milne.

 drivers/scsi/scsi_sysfs.c  | 4 
 include/scsi/scsi_device.h | 2 +-
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0734927..82dfe07 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
struct request_queue *rq = sdev->request_queue;
struct scsi_target *starget = sdev->sdev_target;
 
-   error = scsi_device_set_state(sdev, SDEV_RUNNING);
-   if (error)
-   return error;
-
error = scsi_target_add(starget);
if (error)
return error;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 8990e58..5c53cf5 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -31,7 +31,7 @@ struct scsi_mode_data {
 enum scsi_device_state {
SDEV_CREATED = 1,   /* device created but not added to sysfs
 * Only internal commands allowed (for inq) */
-   SDEV_RUNNING,   /* device properly configured
+   SDEV_RUNNING,   /* device properly initialized
 * All commands allowed */
SDEV_CANCEL,/* beginning to delete device
 * Only error handler commands allowed */
-- 
2.4.11

--
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: libcxgbi: return error if interface is not up

[Varun Prakash]

Do not post hw active open cmd if IFF_UP is not set
or link is down on the interface, return -ENETDOWN
in this case.

Signed-off-by: Varun Prakash 
---
 drivers/scsi/cxgbi/libcxgbi.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 9f4fde9..9167bcd 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -642,6 +642,12 @@ static struct cxgbi_sock *cxgbi_check_route(struct 
sockaddr *dst_addr)
n->dev->name, ndev->name, mtu);
}
 
+   if (!(ndev->flags & IFF_UP) || !netif_carrier_ok(ndev)) {
+   pr_info("%s interface not up.\n", ndev->name);
+   err = -ENETDOWN;
+   goto rel_neigh;
+   }
+
cdev = cxgbi_device_find_by_netdev(ndev, );
if (!cdev) {
pr_info("dst %pI4, %s, NOT cxgbi device.\n",
@@ -736,6 +742,12 @@ static struct cxgbi_sock *cxgbi_check_route6(struct 
sockaddr *dst_addr)
}
ndev = n->dev;
 
+   if (!(ndev->flags & IFF_UP) || !netif_carrier_ok(ndev)) {
+   pr_info("%s interface not up.\n", ndev->name);
+   err = -ENETDOWN;
+   goto rel_rt;
+   }
+
if (ipv6_addr_is_multicast(>sin6_addr)) {
pr_info("multi-cast route %pI6 port %u, dev %s.\n",
daddr6->sin6_addr.s6_addr,
-- 
2.0.2

--
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