Re: [PATCH v2 00/13] lpfc updates for 12.0.0.2

2018-04-09 Thread Martin K. Petersen

James,

> This patch contains lpfc bug fixes
>
> The patches were cut against the Martin's 4.17/scsi-queue tree

Applied to 4.18/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [Resend Patch 1/3] Vmbus: Add function to report available ring buffer to write in total ring size percentage

2018-04-09 Thread Martin K. Petersen

Long,

> I hope this patch set goes through SCSI, because it's purpose is to
> improve storvsc.
>
> If this strategy is not possible, I can resubmit the 1st two patches to
> net, and the 3rd patch to scsi after the 1st two are merged.

Applied to my staging tree for 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH 0/2] megaraid_sas: driver fixes and updates

2018-04-09 Thread Martin K. Petersen

Shivasharan,

> Himanshu Jha (1):
>   megaraid_sas: Use zeroing memory allocator than allocator/memset
>
> Shivasharan S (2):
>   megaraid_sas: Increase timeout by 1 sec for non-RAID fastpath IOs
>   megaraid_sas: driver version upgrade

Applied to 4.18/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH 0/8] hisi_sas: some misc changes

2018-04-09 Thread Martin K. Petersen

John,

> This patchset introduces some minor, more trivial patches, some of
> which have been sitting on our internal dev branch for a while.

Applied to 4.18/scsi-queue. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-09 Thread Michael Schmitz
Hi Christoph,

thanks for your review.

Short of a complete rewrite of the Zorro driver support code to be
closer to what PCI does, I don' see what can be done about the use of
Zorro IDs. I don't think such a rewrite is planned in the near future,
Geert?

I can certainly use board type enums as index into a driver data (or
feature) struct array made up from the current board config data. Adds
another level of indirection while still keeping the probe code
readable. Even allows to drop the last use of these long zorro_id
macros in the probe function, and that's a clear win.
I just wouldn't want to revert to patching up bits of config data
based on board type later - we had arrived at the current code after
quite some review with input from Finn and Geert.

May take a while to test any changes though (my test box appears to be
on the move at present).

Cheers,

  Michael



On Mon, Apr 9, 2018 at 7:50 PM, Christoph Hellwig  wrote:
> On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
>> New combined SCSI driver for all ESP based Zorro SCSI boards for
>> m68k Amiga.
>>
>> Code largely based on board specific parts of the old drivers (blz1230.c,
>> blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed
>> after the 2.6 kernel series for lack of maintenance) with contributions
>> by Tuomas Vainikka (TCQ bug tests and workaround) and Finn Thain (TCQ
>> bugfix by use of PIO in extended message in transfer).
>>
>> New Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI
>> driver included in this patch.
>>
>> Use DMA transfers wherever possible, with board-specific DMA set-up
>> functions copied from the old driver code. Three byte reselection messages
>> do appear to cause DMA timeouts. So wire up a PIO transfer routine for
>> these instead. esp_reselect_with_tag explicitly sets esp->cmd_block_dma as
>> target address for the message bytes but PIO requires a virtual address.
>> Substiute kernel virtual address esp->cmd_block in PIO transfer call if
>> DMA address is esp->cmd_block_dma and phase is message in.
>>
>> PIO code taken from mac_esp.c where the reselection timeout issue was
>> debugged and fixed first, with minor macro and function rename.
>>
>> Signed-off-by: Michael Schmitz 
>> Reviewed-by: Finn Thain 
>>
>> ---
>>
>> Changes since v1:
>>
>> Fixed issues raised by Finn Thain in initial code review:
>>
>> - use KBUILD_MODNAME for driver name string.
>> - use pr_fmt() for pr_* format prefix.
>> - clean up DMA error reporting: clear error flag before each DMA
>>   operation, set error flag on PIO error. Don't test phase in dma_err hook.
>> - change confusing comment about semantics of read flag, add comments
>>   indicating DMA direction to DMA setup hooks.
>> - drop spurious braces around switch clauses.
>> - lift cfreq setting out of ID switch clauses.
>> - fix indentation.
>> - fix error codes on probe fail.
>> - drop check for board ID when unmapping DMA regs in error handling:
>>   the ioaddr > 0xff test already catches all cases where the DMA
>>   registers were ioremapped.
>> - dynamically alloc zorro_private_data.
>> - fix use of driver_data field (don't mix host and zorro_esp_priv
>>   pointers). Note: require esp pointer in zorro_esp_priv to find host
>>   pointer!
>> - back out phase bits changes to pio_cmd !write branch introduced
>>   to cope with ESP SELAS command. We don't use that code so keep
>>   it in sync with Finn's version.
>> - use esp_ops.dma_length_limit() to limit transfer size. After review
>>   of old driver code, use 0xff max transfer size throughout.
>>
>> Fixed issues raised by Geert Uytterhoven:
>>
>> - dynamically alloc zorro_private_data, store as device drvdata.
>> - store ctrl_data for CyberStormI in driver private data.
>> - use dma_sync_single_for_device() instead of cache_push/clear.
>> - handle case of duplicate board identity - check whether board is
>>   Zorro III or Zorro II (use ROM resource data for this). Also fix
>>   up DMA mask for Zorro II boards to 32 bits (these are really CPU
>>   expansion slot boards).
>> - remove zorro3 field from driver_data struct (now in private data).
>> - add braces around ambiguous if - else construct.
>> - use named structs instead of array for board config data.
>> - use scsi_option driver data flag for boards with optional ESP.
>>
>> Other improvements and bugfixes
>>
>> - fix Zorro device table error (duplicate ID used, also raised
>>   by Kars de Jong).
>> - error code fixup in error handling path.
>> - add separate DMA setup for Blizzard 1230 II board.
>> - add support for Cyberstorm II board.
>> - add register structs and DMA setup for Zorro III Fastlane board,
>>   following logic from old fastlane.c driver. Wire up Fastlane DMA
>>   and interrupt status routines, map the necessary low 24 bit board
>>   address space used for DMA target address setting. Clean up DMA
>>   register space ioremap() 

Re: [PATCH v2] scsi: cxgb4i: silence overflow warning in t4_uld_rx_handler()

2018-04-09 Thread Martin K. Petersen

Dan,

> Smatch marks skb->data as untrusted so it complains that there is a
> potential overflow here:
>
>   drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:2111 t4_uld_rx_handler()
>   error: buffer overflow 'cxgb4i_cplhandlers' 239 <= 255.
>
> In this case, skb->data comes from the hardware or firmware so it's not
> going to overflow unless there is a firmware bug.

Applied to 4.17/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: devinfo: Add Microsoft iSCSI target to 1024 sector blacklist

2018-04-09 Thread Martin K. Petersen

Ross,

> The Windows Server 2016 iSCSI target doesn't work with the Linux
> kernel initiator since the kernel started sending larger requests by
> default, nor does it implement the block limits VPD page. Apply the
> sector limit workaround for these targets.

Applied to 4.17/scsi-fixes, thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: dpt_i2o: Use after free in I2ORESETCMD ioctl

2018-04-09 Thread Martin K. Petersen

Dan,

> Here is another use after free if we reset the card.  The adpt_hba_reset()
> function frees "pHba" on error.

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v3 0/3] Report all request failures again to user space

2018-04-09 Thread Martin K. Petersen

Johannes,

> I did start a series [1] for this but than got distracted by more urgent
> things. I can pick it up again I think.
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=iscsi_DID_REQUEUE

Definitely a step in the right direction.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v3 0/3] Report all request failures again to user space

2018-04-09 Thread Martin K. Petersen

Bart,

> A recent change in the SCSI core caused certain request failures no
> longer to be reported to user space. Damien noticed this by sending a
> write request that is not aligned to the write pointer to an SMR drive
> from user space. Such non-aligned write requests are failed by the
> drive and such failures should be reported to user space. This patch
> series makes sure that all SCSI request failures are again reported to
> user space. This patch series also makes the SCSI core recognize
> status codes like CONDITION MET as not being an error.  Please
> consider at least the first patch in this series for the rc stage of
> kernel v4.17.

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION

2018-04-09 Thread Martin K. Petersen

Johannes,

> Bart reports that in qla_isr.c's qla2x00_handle_dif_error we're
> wrongly shifting the SAM_STAT_CHECK_CONDITION by one instead of
> directly ORing it onto the SCSI command's result.

Applied to 4.17/scsi-fixes. Thx!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v2] qla2xxx: correctly shift host byte

2018-04-09 Thread Martin K. Petersen

Johannes,

> The SCSI host byte has to be shifted by 16 not 6.
>
> As Bart pointed out this patch does not change any functionality
> because DID_OK == 0, but a wrong shift is irritating for the reviewer.

Applied to 4.17/scsi-fixes. Thank you!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] aacraid: Insure command thread is not recursively stopped

2018-04-09 Thread Martin K. Petersen

Dave,

> If a recursive IOP_RESET is invoked, usually due to the eh_thread
> handling errors after the first reset, be sure we flag that the
> command thread has been stopped to avoid an Oops of the form;

Applied to 4.17/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] qla2xxx: Avoid double completion of abort command

2018-04-09 Thread Martin K. Petersen

Himanshu,

>> qla2x00_tmf_sp_done() now deletes the timer that will run
>> qla2x00_tmf_iocb_timeout(), but doesn't check whether the timer
>> already expired.  Check the return value from del_timer() to avoid
>> calling complete() a second time.

> Looks good.
>
> Acked-by: Himanshu Madhani 

Applied to 4.17/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH v2] qla2xxx: Fix race condition between iocb timeout and initialisation

2018-04-09 Thread Martin K. Petersen

Himanshu,

> Thanks again for the patch. Testing was successful. 
>
> Acked-by: Himanshu Madhani 

Applied to 4.17/scsi-fixes. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: 4.15.14 crash with iscsi target and dvd

2018-04-09 Thread Ming Lei
On Mon, Apr 09, 2018 at 07:43:01PM -0400, Wakko Warner wrote:
> Ming Lei wrote:
> > On Mon, Apr 09, 2018 at 09:30:11PM +, Bart Van Assche wrote:
> > > Hello Ming,
> > > 
> > > Can you have a look at this? The start of this e-mail thread is available 
> > > at
> > > https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg72574.html.
> > 
> > Sure, thanks for your sharing.
> > 
> > Wakko, could you test the following patch and see if there is any
> > difference?
> 
> Sure, one question, is this against 4.15 or does it matter.  Last I looked,
> 4.16 hasn't changed from 4.15 for that file.

It is two-line change, and I am sure it can be applied on 4.15 cleanly. 

Thanks,
Ming


Re: 4.15.14 crash with iscsi target and dvd

2018-04-09 Thread Wakko Warner
Ming Lei wrote:
> On Mon, Apr 09, 2018 at 09:30:11PM +, Bart Van Assche wrote:
> > Hello Ming,
> > 
> > Can you have a look at this? The start of this e-mail thread is available at
> > https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg72574.html.
> 
> Sure, thanks for your sharing.
> 
> Wakko, could you test the following patch and see if there is any
> difference?

Sure, one question, is this against 4.15 or does it matter.  Last I looked,
4.16 hasn't changed from 4.15 for that file.

> diff --git a/drivers/target/target_core_pscsi.c 
> b/drivers/target/target_core_pscsi.c
> index 0d99b242e82e..6147178f1f37 100644
> --- a/drivers/target/target_core_pscsi.c
> +++ b/drivers/target/target_core_pscsi.c
> @@ -888,7 +888,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, 
> u32 sgl_nents,
>   if (len > 0 && data_len > 0) {
>   bytes = min_t(unsigned int, len, PAGE_SIZE - off);
>   bytes = min(bytes, data_len);
> -
> + new_bio:
>   if (!bio) {
>   nr_vecs = min_t(int, BIO_MAX_PAGES, nr_pages);
>   nr_pages -= nr_vecs;
> @@ -931,6 +931,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, 
> u32 sgl_nents,
>* be allocated with pscsi_get_bio() above.
>*/
>   bio = NULL;
> + goto new_bio;
>   }
>  
>   data_len -= bytes;
> 
> -- 
> Ming
-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.


Re: 4.15.14 crash with iscsi target and dvd

2018-04-09 Thread Ming Lei
On Mon, Apr 09, 2018 at 09:30:11PM +, Bart Van Assche wrote:
> On Sun, 2018-04-08 at 12:02 -0400, Wakko Warner wrote:
> > I finished with git bisect.  Here's the output:
> > 84c8590646d5b35804bac60eb58b145839b5893e is the first bad commit
> > commit 84c8590646d5b35804bac60eb58b145839b5893e
> > Author: Ming Lei 
> > Date:   Fri Nov 11 20:05:32 2016 +0800
> > 
> > target: avoid accessing .bi_vcnt directly
> > 
> > When the bio is full, bio_add_pc_page() will return zero,
> > so use this information tell when the bio is full.
> > 
> > Also replace access to .bi_vcnt for pr_debug() with bio_segments().
> > 
> > Reviewed-by: Christoph Hellwig 
> > Signed-off-by: Ming Lei 
> > Reviewed-by: Sagi Grimberg 
> > Signed-off-by: Jens Axboe 
> > 
> > :04 04 a3ebbb71c52ee4eb8c3be4d033b81179211bf704 
> > de39a328dbd1b18519946b3ad46d9302886e0dd0 M  drivers
> > 
> > I did a diff between HEAD^ and HEAD and manually patched the file from
> > 4.15.14.  It's not an exact revert.  I'm running it now and it's working.
> > I'll do a better test later on.  Here's the patch:
> > 
> > --- a/drivers/target/target_core_pscsi.c2018-02-04 14:31:31.077316617 
> > -0500
> > +++ b/drivers/target/target_core_pscsi.c2018-04-08 11:43:49.588641374 
> > -0400
> > @@ -915,7 +915,9 @@
> > bio, page, bytes, off);
> > pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
> > bio_segments(bio), nr_vecs);
> > -   if (rc != bytes) {
> > +   if (rc != bytes)
> > +   goto fail;
> > +   if (bio->bi_vcnt > nr_vecs) {
> > pr_debug("PSCSI: Reached bio->bi_vcnt max:"
> > " %d i: %d bio: %p, allocating another"
> > " bio\n", bio->bi_vcnt, i, bio);
> 
> Hello Ming,
> 
> Can you have a look at this? The start of this e-mail thread is available at
> https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg72574.html.

Sure, thanks for your sharing.

Wakko, could you test the following patch and see if there is any
difference?

--
diff --git a/drivers/target/target_core_pscsi.c 
b/drivers/target/target_core_pscsi.c
index 0d99b242e82e..6147178f1f37 100644
--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -888,7 +888,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, 
u32 sgl_nents,
if (len > 0 && data_len > 0) {
bytes = min_t(unsigned int, len, PAGE_SIZE - off);
bytes = min(bytes, data_len);
-
+ new_bio:
if (!bio) {
nr_vecs = min_t(int, BIO_MAX_PAGES, nr_pages);
nr_pages -= nr_vecs;
@@ -931,6 +931,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist *sgl, 
u32 sgl_nents,
 * be allocated with pscsi_get_bio() above.
 */
bio = NULL;
+   goto new_bio;
}
 
data_len -= bytes;

-- 
Ming


Re: [PATCH] iscsi: respond to netlink with unicast when appropriate

2018-04-09 Thread Lee Duncan
On 04/09/2018 03:15 PM, Chris Leech wrote:
> Instead of always multicasting responses, send a unicast netlink message
> directed at the correct pid.  This will be needed if we ever want to
> support multiple userspace processes interacting with the kernel over
> iSCSI netlink simultaneously.  Limitations can currently be seen if you
> attempt to run multiple iscsistart commands in parallel.
> 
> We've fixed up the userspace issues in iscsistart that prevented
> multiple instances from running, so now attempts to speed up booting by
> bringing up multiple iscsi sessions at once in the initramfs are just
> running into misrouted responses that this fixes.

As you may know, I disagree with running multiple iscsistart-s at the
same time, since that's what iscsid is for.

Never the less, I believe we _should_ be able to have multiple processes
talking to the kernel target code, so I agree with these changes.

> 
> Signed-off-by: Chris Leech 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 29 ++---
>  1 file changed, 18 insertions(+), 11 deletions(-)
> 
> ... (diffs removed to save electrons)
> 

Reviewed-by: Lee Duncan 
-- 
Lee Duncan
SUSE Labs


Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Kees Cook
On Mon, Apr 9, 2018 at 1:30 PM, Kees Cook  wrote:
> Ah! dm-crypt too. I'll see if I can get that added easily to my tests.

Quick update: I added dm-crypt (with XFS on top) and it hung my system
almost immediately. I got no warnings at all, though.

-Kees

-- 
Kees Cook
Pixel Security


[PATCH] iscsi: respond to netlink with unicast when appropriate

2018-04-09 Thread Chris Leech
Instead of always multicasting responses, send a unicast netlink message
directed at the correct pid.  This will be needed if we ever want to
support multiple userspace processes interacting with the kernel over
iSCSI netlink simultaneously.  Limitations can currently be seen if you
attempt to run multiple iscsistart commands in parallel.

We've fixed up the userspace issues in iscsistart that prevented
multiple instances from running, so now attempts to speed up booting by
bringing up multiple iscsi sessions at once in the initramfs are just
running into misrouted responses that this fixes.

Signed-off-by: Chris Leech 
---
 drivers/scsi/scsi_transport_iscsi.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index f4b52b44b966..65f6c94f2e9b 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb, uint32_t group, 
gfp_t gfp)
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+{
+   return nlmsg_unicast(nls, skb, portid);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host_no, struct 
iscsi_transport *transport,
 EXPORT_SYMBOL_GPL(iscsi_ping_comp_event);
 
 static int
-iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,
-   void *payload, int size)
+iscsi_if_send_reply(u32 portid, int type, void *payload, int size)
 {
struct sk_buff  *skb;
struct nlmsghdr *nlh;
int len = nlmsg_total_size(size);
-   int flags = multi ? NLM_F_MULTI : 0;
-   int t = done ? NLMSG_DONE : type;
 
skb = alloc_skb(len, GFP_ATOMIC);
if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int seq, int type, 
int done, int multi,
return -ENOMEM;
}
 
-   nlh = __nlmsg_put(skb, 0, 0, t, (len - sizeof(*nlh)), 0);
-   nlh->nlmsg_flags = flags;
+   nlh = __nlmsg_put(skb, 0, 0, type, (len - sizeof(*nlh)), 0);
memcpy(nlmsg_data(nlh), payload, size);
-   return iscsi_multicast_skb(skb, group, GFP_ATOMIC);
+   return iscsi_unicast_skb(skb, portid);
 }
 
 static int
@@ -3470,6 +3472,7 @@ static int
 iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
 {
int err = 0;
+   u32 portid;
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct iscsi_transport *transport = NULL;
struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr 
*nlh, uint32_t *group)
if (!try_module_get(transport->owner))
return -EINVAL;
 
+   portid = NETLINK_CB(skb).portid;
+
switch (nlh->nlmsg_type) {
case ISCSI_UEVENT_CREATE_SESSION:
err = iscsi_if_create_session(priv, ep, ev,
- NETLINK_CB(skb).portid,
+ portid,
  ev->u.c_session.initial_cmdsn,
  ev->u.c_session.cmds_max,
  ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr 
*nlh, uint32_t *group)
}
 
err = iscsi_if_create_session(priv, ep, ev,
-   NETLINK_CB(skb).portid,
+   portid,
ev->u.c_bound_session.initial_cmdsn,
ev->u.c_bound_session.cmds_max,
ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr 
*nlh, uint32_t *group)
 static void
 iscsi_if_rx(struct sk_buff *skb)
 {
+   u32 portid = NETLINK_CB(skb).portid;
+
mutex_lock(_queue_mutex);
while (skb->len >= NLMSG_HDRLEN) {
int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
-   err = iscsi_if_send_reply(group, nlh->nlmsg_seq,
-   nlh->nlmsg_type, 0, 0, ev, sizeof(*ev));
+   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ ev, sizeof(*ev));
} while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
skb_pull(skb, rlen);
}
-- 
2.14.3



Re: 4.15.14 crash with iscsi target and dvd

2018-04-09 Thread Bart Van Assche
On Sun, 2018-04-08 at 12:02 -0400, Wakko Warner wrote:
> I finished with git bisect.  Here's the output:
> 84c8590646d5b35804bac60eb58b145839b5893e is the first bad commit
> commit 84c8590646d5b35804bac60eb58b145839b5893e
> Author: Ming Lei 
> Date:   Fri Nov 11 20:05:32 2016 +0800
> 
> target: avoid accessing .bi_vcnt directly
> 
> When the bio is full, bio_add_pc_page() will return zero,
> so use this information tell when the bio is full.
> 
> Also replace access to .bi_vcnt for pr_debug() with bio_segments().
> 
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Ming Lei 
> Reviewed-by: Sagi Grimberg 
> Signed-off-by: Jens Axboe 
> 
> :04 04 a3ebbb71c52ee4eb8c3be4d033b81179211bf704 
> de39a328dbd1b18519946b3ad46d9302886e0dd0 M  drivers
> 
> I did a diff between HEAD^ and HEAD and manually patched the file from
> 4.15.14.  It's not an exact revert.  I'm running it now and it's working.
> I'll do a better test later on.  Here's the patch:
> 
> --- a/drivers/target/target_core_pscsi.c  2018-02-04 14:31:31.077316617 
> -0500
> +++ b/drivers/target/target_core_pscsi.c  2018-04-08 11:43:49.588641374 
> -0400
> @@ -915,7 +915,9 @@
>   bio, page, bytes, off);
>   pr_debug("PSCSI: bio->bi_vcnt: %d nr_vecs: %d\n",
>   bio_segments(bio), nr_vecs);
> - if (rc != bytes) {
> + if (rc != bytes)
> + goto fail;
> + if (bio->bi_vcnt > nr_vecs) {
>   pr_debug("PSCSI: Reached bio->bi_vcnt max:"
>   " %d i: %d bio: %p, allocating another"
>   " bio\n", bio->bi_vcnt, i, bio);

Hello Ming,

Can you have a look at this? The start of this e-mail thread is available at
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg72574.html.

Thanks,

Bart.





[PATCH v2 04/13] lpfc: Enlarge nvmet asynchronous receive buffer counts

2018-04-09 Thread James Smart
Under large io load, the current sizing of asynchronous buffer counts
could be exceeded, indicated by a 2885 log message:
  2885 Port Status Event: port status reg 0x8180, port smphr
  reg 0xc000, error 1=0x52004a01, error 2=0x0

Enlarge the async receive queue size.  Allow for a configurable number
of buffers to be posted to each RQ, using the new attribute
lpfc_nvmet_mrq_post.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc.h   |  1 +
 drivers/scsi/lpfc/lpfc_attr.c  | 11 +++
 drivers/scsi/lpfc/lpfc_nvmet.h |  6 --
 drivers/scsi/lpfc/lpfc_sli.c   |  2 +-
 4 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 2b47c69c1732..20b249a649dd 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -782,6 +782,7 @@ struct lpfc_hba {
uint32_t cfg_nvme_oas;
uint32_t cfg_nvme_embed_cmd;
uint32_t cfg_nvme_io_channel;
+   uint32_t cfg_nvmet_mrq_post;
uint32_t cfg_nvmet_mrq;
uint32_t cfg_enable_nvmet;
uint32_t cfg_nvme_enable_fb;
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 3a6b1be18886..15f921d8ea56 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -3424,6 +3424,15 @@ LPFC_ATTR_R(nvmet_mrq,
"Specify number of RQ pairs for processing NVMET cmds");
 
 /*
+ * lpfc_nvmet_mrq_post: Specify number of RQ buffer to initially post
+ * to each NVMET RQ. Range 64 to 2048, default is 512.
+ */
+LPFC_ATTR_R(nvmet_mrq_post,
+   LPFC_NVMET_RQE_DEF_POST, LPFC_NVMET_RQE_MIN_POST,
+   LPFC_NVMET_RQE_DEF_COUNT,
+   "Specify number of RQ buffers to initially post");
+
+/*
  * lpfc_enable_fc4_type: Defines what FC4 types are supported.
  * Supported Values:  1 - register just FCP
  *3 - register both FCP and NVME
@@ -5353,6 +5362,7 @@ struct device_attribute *lpfc_hba_attrs[] = {
_attr_lpfc_suppress_rsp,
_attr_lpfc_nvme_io_channel,
_attr_lpfc_nvmet_mrq,
+   _attr_lpfc_nvmet_mrq_post,
_attr_lpfc_nvme_enable_fb,
_attr_lpfc_nvmet_fb_size,
_attr_lpfc_enable_bg,
@@ -6403,6 +6413,7 @@ lpfc_get_cfgparam(struct lpfc_hba *phba)
 
lpfc_enable_fc4_type_init(phba, lpfc_enable_fc4_type);
lpfc_nvmet_mrq_init(phba, lpfc_nvmet_mrq);
+   lpfc_nvmet_mrq_post_init(phba, lpfc_nvmet_mrq_post);
 
/* Initialize first burst. Target vs Initiator are different. */
lpfc_nvme_enable_fb_init(phba, lpfc_nvme_enable_fb);
diff --git a/drivers/scsi/lpfc/lpfc_nvmet.h b/drivers/scsi/lpfc/lpfc_nvmet.h
index c1bcef3f103c..81f520abfd64 100644
--- a/drivers/scsi/lpfc/lpfc_nvmet.h
+++ b/drivers/scsi/lpfc/lpfc_nvmet.h
@@ -22,8 +22,10 @@
  /
 
 #define LPFC_NVMET_DEFAULT_SEGS(64 + 1)/* 256K IOs */
-#define LPFC_NVMET_RQE_DEF_COUNT   512
-#define LPFC_NVMET_SUCCESS_LEN 12
+#define LPFC_NVMET_RQE_MIN_POST128
+#define LPFC_NVMET_RQE_DEF_POST512
+#define LPFC_NVMET_RQE_DEF_COUNT   2048
+#define LPFC_NVMET_SUCCESS_LEN 12
 
 #define LPFC_NVMET_MRQ_OFF 0x
 #define LPFC_NVMET_MRQ_AUTO0
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index cb17e2b2be81..e0a8c8008195 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -7199,7 +7199,7 @@ lpfc_sli4_hba_setup(struct lpfc_hba *phba)
lpfc_post_rq_buffer(
phba, phba->sli4_hba.nvmet_mrq_hdr[i],
phba->sli4_hba.nvmet_mrq_data[i],
-   LPFC_NVMET_RQE_DEF_COUNT, i);
+   phba->cfg_nvmet_mrq_post, i);
}
}
 
-- 
2.13.1



[PATCH v2 13/13] lpfc: update driver version to 12.0.0.2

2018-04-09 Thread James Smart
Update the driver version to 12.0.0.2

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_version.h b/drivers/scsi/lpfc/lpfc_version.h
index e8b089abbfb3..0cd474bb0bdd 100644
--- a/drivers/scsi/lpfc/lpfc_version.h
+++ b/drivers/scsi/lpfc/lpfc_version.h
@@ -20,7 +20,7 @@
  * included with this package. *
  ***/
 
-#define LPFC_DRIVER_VERSION "12.0.0.1"
+#define LPFC_DRIVER_VERSION "12.0.0.2"
 #define LPFC_DRIVER_NAME   "lpfc"
 
 /* Used for SLI 2/3 */
-- 
2.13.1



[PATCH v2 08/13] lpfc: Fix WQ/CQ creation for older asic's.

2018-04-09 Thread James Smart
The patch to enlarge WQ/CQ creation keys off of an adapter
response that indicates support for the larger values. Older
adapters return an incorrect response and are limited in size.
Thus the adapters fail the WQ creation steps.

Augment the WQ sizing checks with a check on the older adapter
types and limit them to the restricted sizes.

Fixes: c176ffa0841c ("scsi: lpfc: Increase CQ and WQ sizes for SCSI")
Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_hw4.h  | 12 
 drivers/scsi/lpfc/lpfc_init.c | 15 +++
 drivers/scsi/lpfc/lpfc_sli4.h |  1 +
 3 files changed, 28 insertions(+)

diff --git a/drivers/scsi/lpfc/lpfc_hw4.h b/drivers/scsi/lpfc/lpfc_hw4.h
index 98b80559c215..9df1c8da6f52 100644
--- a/drivers/scsi/lpfc/lpfc_hw4.h
+++ b/drivers/scsi/lpfc/lpfc_hw4.h
@@ -104,6 +104,17 @@ struct lpfc_sli_intf {
 #define LPFC_SLI_INTF_IF_TYPE_VIRT 1
 };
 
+struct lpfc_sli_asic_rev {
+   u32 word0;
+#define LPFC_SLI_ASIC_VER_A0x0
+#define LPFC_SLI_ASIC_VER_B0x1
+#define LPFC_SLI_ASIC_VER_C0x2
+#define LPFC_SLI_ASIC_VER_D0x3
+#define lpfc_sli_asic_ver_SHIFT4
+#define lpfc_sli_asic_ver_MASK 0x000F
+#define lpfc_sli_asic_ver_WORD word0
+};
+
 #define LPFC_SLI4_MBX_EMBEDtrue
 #define LPFC_SLI4_MBX_NEMBED   false
 
@@ -566,6 +577,7 @@ struct lpfc_register {
 
 /* The following BAR0 register sets are defined for if_type 0 and 2 UCNAs. */
 #define LPFC_SLI_INTF  0x0058
+#define LPFC_SLI_ASIC_VER  0x009C
 
 #define LPFC_CTL_PORT_SEM_OFFSET   0x400
 #define lpfc_port_smphr_perr_SHIFT 31
diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 8dac676a46db..060f0e2f6ff5 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -9514,6 +9514,11 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba)
return error;
}
 
+   if (pci_read_config_dword(pdev, LPFC_SLI_ASIC_VER,
+ >sli4_hba.sli_asic_ver.word0)) {
+   return error;
+   }
+
/* There is no SLI3 failback for SLI4 devices. */
if (bf_get(lpfc_sli_intf_valid, >sli4_hba.sli_intf) !=
LPFC_SLI_INTF_VALID) {
@@ -10545,6 +10550,7 @@ lpfc_get_sli4_parameters(struct lpfc_hba *phba, 
LPFC_MBOXQ_t *mboxq)
struct lpfc_pc_sli4_params *sli4_params;
uint32_t mbox_tmo;
int length;
+   bool exp_wqcq_pages = true;
struct lpfc_sli4_parameters *mbx_sli4_parameters;
 
/*
@@ -10671,8 +10677,17 @@ lpfc_get_sli4_parameters(struct lpfc_hba *phba, 
LPFC_MBOXQ_t *mboxq)
phba->nvme_support, phba->nvme_embed_pbde,
phba->cfg_nvme_embed_cmd, phba->cfg_suppress_rsp);
 
+   if ((bf_get(lpfc_sli_intf_if_type, >sli4_hba.sli_intf) ==
+   LPFC_SLI_INTF_IF_TYPE_2) &&
+   (bf_get(lpfc_sli_intf_sli_family, >sli4_hba.sli_intf) ==
+LPFC_SLI_INTF_FAMILY_LNCR_A0) &&
+   (bf_get(lpfc_sli_asic_ver, >sli4_hba.sli_asic_ver) ==
+   LPFC_SLI_ASIC_VER_A))
+   exp_wqcq_pages = false;
+
if ((bf_get(cfg_cqpsize, mbx_sli4_parameters) & LPFC_CQ_16K_PAGE_SZ) &&
(bf_get(cfg_wqpsize, mbx_sli4_parameters) & LPFC_WQ_16K_PAGE_SZ) &&
+   exp_wqcq_pages &&
(sli4_params->wqsize & LPFC_WQ_SZ128_SUPPORT))
phba->enab_exp_wqcq_pages = 1;
else
diff --git a/drivers/scsi/lpfc/lpfc_sli4.h b/drivers/scsi/lpfc/lpfc_sli4.h
index cf64aca82bd0..179e870a00b4 100644
--- a/drivers/scsi/lpfc/lpfc_sli4.h
+++ b/drivers/scsi/lpfc/lpfc_sli4.h
@@ -592,6 +592,7 @@ struct lpfc_sli4_hba {
uint32_t ue_to_sr;
uint32_t ue_to_rp;
struct lpfc_register sli_intf;
+   struct lpfc_register sli_asic_ver;
struct lpfc_pc_sli4_params pc_sli4_params;
struct lpfc_bbscn_params bbscn_params;
struct lpfc_hba_eq_hdl *hba_eq_hdl; /* HBA per-WQ handle */
-- 
2.13.1



[PATCH v2 10/13] lpfc: Fix nvme remoteport registration race conditions

2018-04-09 Thread James Smart
On tests adding and removing a remote port, calls to nvme_info would
eventually show fewer target ports discovered than were present in
the san. Additionally, the following error messages were seen:
  6031 RemotePort Registration failed err: -116, DID x471301

There is a race condition that exists between the driver and the nvme
transport on remote port unregister vs the confirmed deletion. It's
possible that the driver may rediscover the remote port and reregister
the remote port before a prior unregister delete callback was made
(as it rebinded to the prior remoteport structure). However, the
driver was coded to expect the callback before seeing the remote
port again thus a new registration. The logic results in the driver
having an invalid remoteport pointer set.

Correct by tracking when waiting for the delete callback. In cases
where the ndlp remoteport pointer is updated, it is only cleared
when the wait has not been superceded by a prior registration.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_nvme.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 22962b08c275..a0257478b63c 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -334,8 +334,14 @@ lpfc_nvme_remoteport_delete(struct nvme_fc_remote_port 
*remoteport)
"6146 remoteport delete of remoteport %p\n",
remoteport);
spin_lock_irq(>phba->hbalock);
-   ndlp->nrport = NULL;
-   ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
+
+   /* The register rebind might have occurred before the delete
+* downcall.  Guard against this race.
+*/
+   if (ndlp->upcall_flags & NLP_WAIT_FOR_UNREG) {
+   ndlp->nrport = NULL;
+   ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
+   }
spin_unlock_irq(>phba->hbalock);
 
/* Remove original register reference. The host transport
@@ -2691,6 +2697,12 @@ lpfc_nvme_register_port(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp)
 * a resume of the existing rport.  Else this is a
 * new rport.
 */
+   /* Guard against an unregister/reregister
+* race that leaves the WAIT flag set.
+*/
+   spin_lock_irq(>phba->hbalock);
+   ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
+   spin_unlock_irq(>phba->hbalock);
rport = remote_port->private;
if (oldrport) {
if (oldrport == remote_port->private) {
-- 
2.13.1



[PATCH v2 06/13] lpfc: Fix lingering lpfc_wq resource after driver unload

2018-04-09 Thread James Smart
After driver unloads lpfc_wq remains active. The destroy_workqueue
calls were not being made in driver unload.  Additionally, SLI3 is
allocating lpfc_wq resources, but never uses it.

Make the destroy_workqueue calls on driver unload.
Modify the SLI3 code path no longer allocate lpfc_wq resources.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_init.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c
index 4add398ec9cf..8dac676a46db 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -6420,8 +6420,11 @@ lpfc_setup_driver_resource_phase2(struct lpfc_hba *phba)
return error;
}
 
-   /* workqueue for deferred irq use */
-   phba->wq = alloc_workqueue("lpfc_wq", WQ_MEM_RECLAIM, 0);
+   /* The lpfc_wq workqueue for deferred irq use, is only used for SLI4 */
+   if (phba->sli_rev == LPFC_SLI_REV4)
+   phba->wq = alloc_workqueue("lpfc_wq", WQ_MEM_RECLAIM, 0);
+   else
+   phba->wq = NULL;
 
return 0;
 }
@@ -6444,7 +6447,8 @@ lpfc_unset_driver_resource_phase2(struct lpfc_hba *phba)
}
 
/* Stop kernel worker thread */
-   kthread_stop(phba->worker_thread);
+   if (phba->worker_thread)
+   kthread_stop(phba->worker_thread);
 }
 
 /**
@@ -11727,6 +11731,7 @@ lpfc_pci_remove_one_s4(struct pci_dev *pdev)
lpfc_nvme_free(phba);
lpfc_free_iocb_list(phba);
 
+   lpfc_unset_driver_resource_phase2(phba);
lpfc_sli4_driver_resource_unset(phba);
 
/* Unmap adapter Control and Doorbell registers */
-- 
2.13.1



[PATCH v2 07/13] lpfc: Fix NULL pointer access in lpfc_nvme_info_show

2018-04-09 Thread James Smart
After making remoteport unregister requests, the ndlp nrport pointer
was stale.

Track when waiting for waiting for unregister completion callback and
adjust nldp pointer assignment.  Add a few safety checks for NULL
pointer values.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_attr.c| 16 
 drivers/scsi/lpfc/lpfc_debugfs.c |  8 ++--
 drivers/scsi/lpfc/lpfc_nvme.c| 13 +
 drivers/scsi/lpfc/lpfc_nvme.h|  4 
 4 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 15f921d8ea56..fd3b25317887 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -149,6 +149,7 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
struct lpfc_nvmet_tgtport *tgtp;
struct nvme_fc_local_port *localport;
struct lpfc_nvme_lport *lport;
+   struct lpfc_nvme_rport *rport;
struct lpfc_nodelist *ndlp;
struct nvme_fc_remote_port *nrport;
struct lpfc_nvme_ctrl_stat *cstat;
@@ -312,11 +313,14 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
localport->port_id, statep);
 
list_for_each_entry(ndlp, >fc_nodes, nlp_listp) {
-   if (!ndlp->nrport)
+   rport = lpfc_ndlp_get_nrport(ndlp);
+   if (!rport)
continue;
 
/* local short-hand pointer. */
-   nrport = ndlp->nrport->remoteport;
+   nrport = rport->remoteport;
+   if (!nrport)
+   continue;
 
/* Port state is only one of two values for now. */
switch (nrport->port_state) {
@@ -3290,6 +3294,9 @@ lpfc_update_rport_devloss_tmo(struct lpfc_vport *vport)
 {
struct Scsi_Host  *shost;
struct lpfc_nodelist  *ndlp;
+#if (IS_ENABLED(CONFIG_NVME_FC))
+   struct lpfc_nvme_rport *rport;
+#endif
 
shost = lpfc_shost_from_vport(vport);
spin_lock_irq(shost->host_lock);
@@ -3299,8 +3306,9 @@ lpfc_update_rport_devloss_tmo(struct lpfc_vport *vport)
if (ndlp->rport)
ndlp->rport->dev_loss_tmo = vport->cfg_devloss_tmo;
 #if (IS_ENABLED(CONFIG_NVME_FC))
-   if (ndlp->nrport)
-   nvme_fc_set_remoteport_devloss(ndlp->nrport->remoteport,
+   rport = lpfc_ndlp_get_nrport(ndlp);
+   if (rport)
+   nvme_fc_set_remoteport_devloss(rport->remoteport,
   vport->cfg_devloss_tmo);
 #endif
}
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index cd3eb6b71398..afe7883c988a 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -552,6 +552,7 @@ lpfc_debugfs_nodelist_data(struct lpfc_vport *vport, char 
*buf, int size)
struct nvme_fc_local_port *localport;
struct lpfc_nvmet_tgtport *tgtp;
struct nvme_fc_remote_port *nrport;
+   struct lpfc_nvme_rport *rport;
 
cnt = (LPFC_NODELIST_SIZE / LPFC_NODELIST_ENTRY_SIZE);
outio = 0;
@@ -695,10 +696,13 @@ lpfc_debugfs_nodelist_data(struct lpfc_vport *vport, char 
*buf, int size)
len += snprintf(buf + len, size - len, "\tRport List:\n");
list_for_each_entry(ndlp, >fc_nodes, nlp_listp) {
/* local short-hand pointer. */
-   if (!ndlp->nrport)
+   rport = lpfc_ndlp_get_nrport(ndlp);
+   if (!rport)
continue;
 
-   nrport = ndlp->nrport->remoteport;
+   nrport = rport->remoteport;
+   if (!nrport)
+   continue;
 
/* Port state is only one of two values for now. */
switch (nrport->port_state) {
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 1414c581c0b6..1cb2c634e9f7 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -335,6 +335,7 @@ lpfc_nvme_remoteport_delete(struct nvme_fc_remote_port 
*remoteport)
remoteport);
spin_lock_irq(>phba->hbalock);
ndlp->nrport = NULL;
+   ndlp->upcall_flags &= ~NLP_WAIT_FOR_UNREG;
spin_unlock_irq(>phba->hbalock);
 
/* Remove original register reference. The host transport
@@ -2646,6 +2647,7 @@ lpfc_nvme_register_port(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp)
struct nvme_fc_local_port *localport;
struct lpfc_nvme_lport *lport;
struct lpfc_nvme_rport *rport;
+   struct lpfc_nvme_rport *oldrport;
struct nvme_fc_remote_port *remote_port;
struct nvme_fc_port_info rpinfo;
struct lpfc_nodelist *prev_ndlp;
@@ -2678,7 

[PATCH v2 05/13] lpfc: Fix Abort request WQ selection

2018-04-09 Thread James Smart
When running loads that generated aborts, io errors where seen.
Turns out the abort requests where not placed on the proper
WQ resulting in the errors. Closer inspection inspection of this
error also showed improper spinlock api use.

Correct the WQ selection policy for the abort requests.
Correct spin_lock/spin_lock_irq/spin_lock_irqsave usage.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_scsi.c | 12 ++--
 drivers/scsi/lpfc/lpfc_sli.c  | 14 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index 8570486013f3..7932bf30c8d7 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -1021,7 +1021,7 @@ lpfc_get_scsi_buf_s4(struct lpfc_hba *phba, struct 
lpfc_nodelist *ndlp)
if (lpfc_test_rrq_active(phba, ndlp,
 lpfc_cmd->cur_iocbq.sli4_lxritag))
continue;
-   list_del(_cmd->list);
+   list_del_init(_cmd->list);
found = 1;
break;
}
@@ -1036,7 +1036,7 @@ lpfc_get_scsi_buf_s4(struct lpfc_hba *phba, struct 
lpfc_nodelist *ndlp)
if (lpfc_test_rrq_active(
phba, ndlp, lpfc_cmd->cur_iocbq.sli4_lxritag))
continue;
-   list_del(_cmd->list);
+   list_del_init(_cmd->list);
found = 1;
break;
}
@@ -4716,7 +4716,7 @@ lpfc_abort_handler(struct scsi_cmnd *cmnd)
int ret = SUCCESS, status = 0;
struct lpfc_sli_ring *pring_s4;
int ret_val;
-   unsigned long flags, iflags;
+   unsigned long flags;
DECLARE_WAIT_QUEUE_HEAD_ONSTACK(waitq);
 
status = fc_block_scsi_eh(cmnd);
@@ -4816,16 +4816,16 @@ lpfc_abort_handler(struct scsi_cmnd *cmnd)
abtsiocb->iocb_cmpl = lpfc_sli_abort_fcp_cmpl;
abtsiocb->vport = vport;
if (phba->sli_rev == LPFC_SLI_REV4) {
-   pring_s4 = lpfc_sli4_calc_ring(phba, iocb);
+   pring_s4 = lpfc_sli4_calc_ring(phba, abtsiocb);
if (pring_s4 == NULL) {
ret = FAILED;
goto out_unlock;
}
/* Note: both hbalock and ring_lock must be set here */
-   spin_lock_irqsave(_s4->ring_lock, iflags);
+   spin_lock(_s4->ring_lock);
ret_val = __lpfc_sli_issue_iocb(phba, pring_s4->ringno,
abtsiocb, 0);
-   spin_unlock_irqrestore(_s4->ring_lock, iflags);
+   spin_unlock(_s4->ring_lock);
} else {
ret_val = __lpfc_sli_issue_iocb(phba, LPFC_FCP_RING,
abtsiocb, 0);
diff --git a/drivers/scsi/lpfc/lpfc_sli.c b/drivers/scsi/lpfc/lpfc_sli.c
index e0a8c8008195..38993efbe37e 100644
--- a/drivers/scsi/lpfc/lpfc_sli.c
+++ b/drivers/scsi/lpfc/lpfc_sli.c
@@ -11300,11 +11300,11 @@ lpfc_sli_abort_taskmgmt(struct lpfc_vport *vport, 
struct lpfc_sli_ring *pring,
unsigned long iflags;
struct lpfc_sli_ring *pring_s4;
 
-   spin_lock_irq(>hbalock);
+   spin_lock_irqsave(>hbalock, iflags);
 
/* all I/Os are in process of being flushed */
if (phba->hba_flag & HBA_FCP_IOQ_FLUSH) {
-   spin_unlock_irq(>hbalock);
+   spin_unlock_irqrestore(>hbalock, iflags);
return 0;
}
sum = 0;
@@ -11366,14 +11366,14 @@ lpfc_sli_abort_taskmgmt(struct lpfc_vport *vport, 
struct lpfc_sli_ring *pring,
iocbq->iocb_flag |= LPFC_DRIVER_ABORTED;
 
if (phba->sli_rev == LPFC_SLI_REV4) {
-   pring_s4 = lpfc_sli4_calc_ring(phba, iocbq);
-   if (pring_s4 == NULL)
+   pring_s4 = lpfc_sli4_calc_ring(phba, abtsiocbq);
+   if (!pring_s4)
continue;
/* Note: both hbalock and ring_lock must be set here */
-   spin_lock_irqsave(_s4->ring_lock, iflags);
+   spin_lock(_s4->ring_lock);
ret_val = __lpfc_sli_issue_iocb(phba, pring_s4->ringno,
abtsiocbq, 0);
-   spin_unlock_irqrestore(_s4->ring_lock, iflags);
+   spin_unlock(_s4->ring_lock);
} else {
ret_val = __lpfc_sli_issue_iocb(phba, pring->ringno,
abtsiocbq, 0);
@@ -11385,7 +11385,7 @@ lpfc_sli_abort_taskmgmt(struct lpfc_vport *vport, 
struct lpfc_sli_ring *pring,

[PATCH v2 12/13] lpfc: Correct missing remoteport registration during link bounces

2018-04-09 Thread James Smart
Remote port disappearance/reappearances would cause a series of RSCN
events to be delivered to the driver. During the resulting GID_FT
handling, the driver clears the fc4 settings on the remote port, which
makes it skip registration. As such, the nvme associations eventually
fail and return io errors to the applications.

Correct by not clearng the nlp_fc4_types for all nodes in lpfc_issue_gidft.
Instead, when the GID_FT response is handled, clear the nlp_fc4_types
of FCP and NVME prior to evaluating the fc4_type returned by the
GID_FT response.  This approach leaves "skipped" nodes with their
nlp_fc4_types intacted.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_ct.c  | 5 +
 drivers/scsi/lpfc/lpfc_hbadisc.c | 4 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 1e7889e45160..d4a200ae5a6f 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -471,6 +471,11 @@ lpfc_prep_node_fc4type(struct lpfc_vport *vport, uint32_t 
Did, uint8_t fc4_type)
"Parse GID_FTrsp: did:x%x flg:x%x x%x",
Did, ndlp->nlp_flag, vport->fc_flag);
 
+   /* Don't assume the rport is always the previous
+* FC4 type.
+*/
+   ndlp->nlp_fc4_type &= ~(NLP_FC4_FCP | NLP_FC4_NVME);
+
/* By default, the driver expects to support FCP FC4 */
if (fc4_type == FC_TYPE_FCP)
ndlp->nlp_fc4_type |= NLP_FC4_FCP;
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index 3e7712cd6c9a..cf2cbaa241b9 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -3876,10 +3876,6 @@ int
 lpfc_issue_gidft(struct lpfc_vport *vport)
 {
struct lpfc_hba *phba = vport->phba;
-   struct lpfc_nodelist *ndlp;
-
-   list_for_each_entry(ndlp, >fc_nodes, nlp_listp)
-   ndlp->nlp_fc4_type &= ~(NLP_FC4_FCP | NLP_FC4_NVME);
 
/* Good status, issue CT Request to NameServer */
if ((phba->cfg_enable_fc4_type == LPFC_ENABLE_BOTH) ||
-- 
2.13.1



[PATCH v2 09/13] lpfc: Fix driver not recovering NVME rports during target link faults

2018-04-09 Thread James Smart
During target-side port faults, the driver would not recover all
target port logins. This resulted in a loss of nvme device discovery.

The driver is coded to wait for all GID_FT requests to complete
before restarting discovery. A fault is seen where the outstanding
GIT_FT counts are not properly decremented, thus discovery would
never start. Another fault was found in the clearing of the gidft_inp
counter that would be skipped in this condition. And a third fault
found with lpfc_nvme_register_port that would remove a reverence
on the ndlp which then allows a node swap on a port address change
to prematurely remove the reference and release the ndlp.

The following changes are made:
Correct the decrementing of the outstanding GID_FT counters.
In RSCN handling, no longer zero the counter before calling to
  issue another GID_FT.
No longer remove the reference on the dlp when the ndlp->nrport
  value is not yet null.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_ct.c   |  5 +
 drivers/scsi/lpfc/lpfc_els.c  |  1 -
 drivers/scsi/lpfc/lpfc_nvme.c | 12 ++--
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 0617c8ea88c6..1e7889e45160 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -691,6 +691,11 @@ lpfc_cmpl_ct_cmd_gid_ft(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdiocb,
vport->fc_flag &= ~FC_RSCN_DEFERRED;
spin_unlock_irq(shost->host_lock);
 
+   /* This is a GID_FT completing so the gidft_inp counter was
+* incremented before the GID_FT was issued to the wire.
+*/
+   vport->gidft_inp--;
+
/*
 * Skip processing the NS response
 * Re-issue the NS cmd
diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
index 74895e62aaea..6d84a10fef07 100644
--- a/drivers/scsi/lpfc/lpfc_els.c
+++ b/drivers/scsi/lpfc/lpfc_els.c
@@ -6268,7 +6268,6 @@ lpfc_els_handle_rscn(struct lpfc_vport *vport)
 * flush the RSCN.  Otherwise, the outstanding requests
 * need to complete.
 */
-   vport->gidft_inp = 0;
if (lpfc_issue_gidft(vport) > 0)
return 1;
} else {
diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index 1cb2c634e9f7..22962b08c275 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -2721,8 +2721,16 @@ lpfc_nvme_register_port(struct lpfc_vport *vport, struct 
lpfc_nodelist *ndlp)
spin_unlock_irq(>phba->hbalock);
rport->ndlp = NULL;
rport->remoteport = NULL;
-   if (prev_ndlp)
-   lpfc_nlp_put(ndlp);
+
+   /* Reference only removed if previous NDLP is no longer
+* active. It might be just a swap and removing the
+* reference would cause a premature cleanup.
+*/
+   if (prev_ndlp && prev_ndlp != ndlp) {
+   if ((!NLP_CHK_NODE_ACT(prev_ndlp)) ||
+   (!prev_ndlp->nrport))
+   lpfc_nlp_put(prev_ndlp);
+   }
}
 
/* Clean bind the rport to the ndlp. */
-- 
2.13.1



[PATCH v2 11/13] lpfc: Fix NULL pointer reference when resetting adapter

2018-04-09 Thread James Smart
Points referencing local port structures didn't accommodate cases
where the localport may not be registered yet.

Add NULL pointer checks to logic.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_nvme.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c
index a0257478b63c..9e0345697e1b 100644
--- a/drivers/scsi/lpfc/lpfc_nvme.c
+++ b/drivers/scsi/lpfc/lpfc_nvme.c
@@ -364,16 +364,18 @@ lpfc_nvme_cmpl_gen_req(struct lpfc_hba *phba, struct 
lpfc_iocbq *cmdwqe,
struct lpfc_dmabuf *buf_ptr;
struct lpfc_nodelist *ndlp;
 
-   lport = (struct lpfc_nvme_lport *)vport->localport->private;
pnvme_lsreq = (struct nvmefc_ls_req *)cmdwqe->context2;
status = bf_get(lpfc_wcqe_c_status, wcqe) & LPFC_IOCB_STATUS_MASK;
 
-   if (lport) {
-   atomic_inc(>fc4NvmeLsCmpls);
-   if (status) {
-   if (bf_get(lpfc_wcqe_c_xb, wcqe))
-   atomic_inc(>cmpl_ls_xb);
-   atomic_inc(>cmpl_ls_err);
+   if (vport->localport) {
+   lport = (struct lpfc_nvme_lport *)vport->localport->private;
+   if (lport) {
+   atomic_inc(>fc4NvmeLsCmpls);
+   if (status) {
+   if (bf_get(lpfc_wcqe_c_xb, wcqe))
+   atomic_inc(>cmpl_ls_xb);
+   atomic_inc(>cmpl_ls_err);
+   }
}
}
 
@@ -980,15 +982,17 @@ lpfc_nvme_io_cmd_wqe_cmpl(struct lpfc_hba *phba, struct 
lpfc_iocbq *pwqeIn,
rport = lpfc_ncmd->nrport;
status = bf_get(lpfc_wcqe_c_status, wcqe);
 
-   lport = (struct lpfc_nvme_lport *)vport->localport->private;
-   if (lport) {
-   idx = lpfc_ncmd->cur_iocbq.hba_wqidx;
-   cstat = >cstat[idx];
-   atomic_inc(>fc4NvmeIoCmpls);
-   if (status) {
-   if (bf_get(lpfc_wcqe_c_xb, wcqe))
-   atomic_inc(>cmpl_fcp_xb);
-   atomic_inc(>cmpl_fcp_err);
+   if (vport->localport) {
+   lport = (struct lpfc_nvme_lport *)vport->localport->private;
+   if (lport) {
+   idx = lpfc_ncmd->cur_iocbq.hba_wqidx;
+   cstat = >cstat[idx];
+   atomic_inc(>fc4NvmeIoCmpls);
+   if (status) {
+   if (bf_get(lpfc_wcqe_c_xb, wcqe))
+   atomic_inc(>cmpl_fcp_xb);
+   atomic_inc(>cmpl_fcp_err);
+   }
}
}
 
-- 
2.13.1



[PATCH v2 02/13] lpfc: Correct target queue depth application changes

2018-04-09 Thread James Smart
The max_scsicmpl_time parameter can be used to perform scsi cmd queue
depth mgmt based on io completion time: the queue depth is reduced to
make completion time shorter. However, as soon as an io completes and
the completion time is within limits, the code immediately bumps the
queue depth limit back up to the target queue depth. Thus the procedure
restarts, effectively limiting the usefulness of adjusting queue depth
to help completion time.

This patch makes the following changes:
Removes the code at io completion that resets the queue depth as soon
  as within limits.
As the code removed was where the target queue depth was first applied,
  change target queue depth application so that it occurs when the
  parameter is changed.
Makes target queue depth a standard parameter: both a module parameter
  and a sysfs parameter.
Optimizes the command pending count by using atomics rather than locks.
Updates the debugfs nodelist stats to allow better debugging of pending
  command counts.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc.h |  2 --
 drivers/scsi/lpfc/lpfc_attr.c| 45 ++--
 drivers/scsi/lpfc/lpfc_debugfs.c | 20 --
 drivers/scsi/lpfc/lpfc_scsi.c| 19 +
 4 files changed, 66 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 6c0d351c0d0d..be4abe52f289 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -64,8 +64,6 @@ struct lpfc_sli2_slim;
 #define LPFC_IOCB_LIST_CNT 2250/* list of IOCBs for fast-path usage. */
 #define LPFC_Q_RAMP_UP_INTERVAL 120 /* lun q_depth ramp up interval */
 #define LPFC_VNAME_LEN 100 /* vport symbolic name length */
-#define LPFC_TGTQ_INTERVAL 4   /* Min amount of time between tgt
-  queue depth change in millisecs */
 #define LPFC_TGTQ_RAMPUP_PCENT 5   /* Target queue rampup in percentage */
 #define LPFC_MIN_TGT_QDEPTH10
 #define LPFC_MAX_TGT_QDEPTH0x
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 2ac1d21c553f..c89ffad1f43d 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -3469,8 +3469,49 @@ LPFC_VPORT_ATTR_R(lun_queue_depth, 30, 1, 512,
 # tgt_queue_depth:  This parameter is used to limit the number of outstanding
 # commands per target port. Value range is [10,65535]. Default value is 65535.
 */
-LPFC_VPORT_ATTR_RW(tgt_queue_depth, 65535, 10, 65535,
-  "Max number of FCP commands we can queue to a specific 
target port");
+static uint lpfc_tgt_queue_depth = LPFC_MAX_TGT_QDEPTH;
+module_param(lpfc_tgt_queue_depth, uint, 0444);
+MODULE_PARM_DESC(lpfc_tgt_queue_depth, "Set max Target queue depth");
+lpfc_vport_param_show(tgt_queue_depth);
+lpfc_vport_param_init(tgt_queue_depth, LPFC_MAX_TGT_QDEPTH,
+ LPFC_MIN_TGT_QDEPTH, LPFC_MAX_TGT_QDEPTH);
+
+/**
+ * lpfc_tgt_queue_depth_store: Sets an attribute value.
+ * @phba: pointer the the adapter structure.
+ * @val: integer attribute value.
+ *
+ * Description: Sets the parameter to the new value.
+ *
+ * Returns:
+ * zero on success
+ * -EINVAL if val is invalid
+ */
+static int
+lpfc_tgt_queue_depth_set(struct lpfc_vport *vport, uint val)
+{
+   struct Scsi_Host *shost = lpfc_shost_from_vport(vport);
+   struct lpfc_nodelist *ndlp;
+
+   if (!lpfc_rangecheck(val, LPFC_MIN_TGT_QDEPTH, LPFC_MAX_TGT_QDEPTH))
+   return -EINVAL;
+
+   if (val == vport->cfg_tgt_queue_depth)
+   return 0;
+
+   spin_lock_irq(shost->host_lock);
+   vport->cfg_tgt_queue_depth = val;
+
+   /* Next loop thru nodelist and change cmd_qdepth */
+   list_for_each_entry(ndlp, >fc_nodes, nlp_listp)
+   ndlp->cmd_qdepth = vport->cfg_tgt_queue_depth;
+
+   spin_unlock_irq(shost->host_lock);
+   return 0;
+}
+
+lpfc_vport_param_store(tgt_queue_depth);
+static DEVICE_ATTR_RW(lpfc_tgt_queue_depth);
 
 /*
 # hba_queue_depth:  This parameter is used to limit the number of outstanding
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c
index fb0dc2aeed91..50c11acf73a8 100644
--- a/drivers/scsi/lpfc/lpfc_debugfs.c
+++ b/drivers/scsi/lpfc/lpfc_debugfs.c
@@ -544,7 +544,7 @@ static int
 lpfc_debugfs_nodelist_data(struct lpfc_vport *vport, char *buf, int size)
 {
int len = 0;
-   int cnt;
+   int i, iocnt, outio, cnt;
struct Scsi_Host *shost = lpfc_shost_from_vport(vport);
struct lpfc_hba  *phba = vport->phba;
struct lpfc_nodelist *ndlp;
@@ -554,10 +554,12 @@ lpfc_debugfs_nodelist_data(struct lpfc_vport *vport, char 
*buf, int size)
struct nvme_fc_remote_port *nrport;
 
cnt = (LPFC_NODELIST_SIZE / LPFC_NODELIST_ENTRY_SIZE);
+   outio = 0;
 

[PATCH v2 03/13] lpfc: Add per io channel NVME IO statistics

2018-04-09 Thread James Smart
When debugging various issues, per IO channel IO statistics were useful
to understand what was happening. However, many of the stats were on a
port basis rather than an io channel basis.

Move statistics to an io channel basis.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc.h |   6 ---
 drivers/scsi/lpfc/lpfc_attr.c|  40 +--
 drivers/scsi/lpfc/lpfc_debugfs.c |  65 
 drivers/scsi/lpfc/lpfc_init.c|  36 -
 drivers/scsi/lpfc/lpfc_nvme.c| 107 ++-
 drivers/scsi/lpfc/lpfc_nvme.h|  10 
 6 files changed, 173 insertions(+), 91 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index be4abe52f289..2b47c69c1732 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -920,12 +920,6 @@ struct lpfc_hba {
atomic_t fc4ScsiOutputRequests;
atomic_t fc4ScsiControlRequests;
atomic_t fc4ScsiIoCmpls;
-   atomic_t fc4NvmeInputRequests;
-   atomic_t fc4NvmeOutputRequests;
-   atomic_t fc4NvmeControlRequests;
-   atomic_t fc4NvmeIoCmpls;
-   atomic_t fc4NvmeLsRequests;
-   atomic_t fc4NvmeLsCmpls;
 
uint64_t bg_guard_err_cnt;
uint64_t bg_apptag_err_cnt;
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index c89ffad1f43d..3a6b1be18886 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -151,8 +151,11 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
struct lpfc_nvme_lport *lport;
struct lpfc_nodelist *ndlp;
struct nvme_fc_remote_port *nrport;
-   uint64_t data1, data2, data3, tot;
+   struct lpfc_nvme_ctrl_stat *cstat;
+   uint64_t data1, data2, data3;
+   uint64_t totin, totout, tot;
char *statep;
+   int i;
int len = 0;
 
if (!(phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME)) {
@@ -364,11 +367,14 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
}
spin_unlock_irq(shost->host_lock);
 
+   if (!lport)
+   return len;
+
len += snprintf(buf + len, PAGE_SIZE - len, "\nNVME Statistics\n");
len += snprintf(buf+len, PAGE_SIZE-len,
"LS: Xmt %010x Cmpl %010x Abort %08x\n",
-   atomic_read(>fc4NvmeLsRequests),
-   atomic_read(>fc4NvmeLsCmpls),
+   atomic_read(>fc4NvmeLsRequests),
+   atomic_read(>fc4NvmeLsCmpls),
atomic_read(>xmt_ls_abort));
 
len += snprintf(buf + len, PAGE_SIZE - len,
@@ -377,28 +383,32 @@ lpfc_nvme_info_show(struct device *dev, struct 
device_attribute *attr,
atomic_read(>cmpl_ls_xb),
atomic_read(>cmpl_ls_err));
 
-   tot = atomic_read(>fc4NvmeIoCmpls);
-   data1 = atomic_read(>fc4NvmeInputRequests);
-   data2 = atomic_read(>fc4NvmeOutputRequests);
-   data3 = atomic_read(>fc4NvmeControlRequests);
+   totin = 0;
+   totout = 0;
+   for (i = 0; i < phba->cfg_nvme_io_channel; i++) {
+   cstat = >cstat[i];
+   tot = atomic_read(>fc4NvmeIoCmpls);
+   totin += tot;
+   data1 = atomic_read(>fc4NvmeInputRequests);
+   data2 = atomic_read(>fc4NvmeOutputRequests);
+   data3 = atomic_read(>fc4NvmeControlRequests);
+   totout += (data1 + data2 + data3);
+   }
len += snprintf(buf+len, PAGE_SIZE-len,
-   "FCP: Rd %016llx Wr %016llx IO %016llx\n",
-   data1, data2, data3);
+   "Total FCP Cmpl %016llx Issue %016llx "
+   "OutIO %016llx\n",
+   totin, totout, totout - totin);
 
len += snprintf(buf+len, PAGE_SIZE-len,
-   "noxri %08x nondlp %08x qdepth %08x "
+   "  abort %08x noxri %08x nondlp %08x qdepth %08x "
"wqerr %08x\n",
+   atomic_read(>xmt_fcp_abort),
atomic_read(>xmt_fcp_noxri),
atomic_read(>xmt_fcp_bad_ndlp),
atomic_read(>xmt_fcp_qdepth),
atomic_read(>xmt_fcp_wqerr));
 
len += snprintf(buf + len, PAGE_SIZE - len,
-   "Cmpl %016llx Outstanding %016llx Abort %08x\n",
-   tot, ((data1 + data2 + data3) - tot),
-   atomic_read(>xmt_fcp_abort));
-
-   len += snprintf(buf + len, PAGE_SIZE - len,
"FCP CMPL: xb %08x Err %08x\n",
atomic_read(>cmpl_fcp_xb),
atomic_read(>cmpl_fcp_err));
diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c 

[PATCH v2 00/13] lpfc updates for 12.0.0.2

2018-04-09 Thread James Smart
This patch contains lpfc bug fixes

The patches were cut against the Martin's 4.17/scsi-queue tree

v2:
  Removed patch:
lpfc: Fix create_association oops on unloading LPFC driver

James Smart (13):
  lpfc: Fix multiple PRLI completion error path
  lpfc: Correct target queue depth application changes
  lpfc: Add per io channel NVME IO statistics
  lpfc: Enlarge nvmet asynchronous receive buffer counts
  lpfc: Fix Abort request WQ selection
  lpfc: Fix lingering lpfc_wq resource after driver unload
  lpfc: Fix NULL pointer access in lpfc_nvme_info_show
  lpfc: Fix WQ/CQ creation for older asic's.
  lpfc: Fix driver not recovering NVME rports during target link faults
  lpfc: Fix nvme remoteport registration race conditions
  lpfc: Fix NULL pointer reference when resetting adapter
  lpfc: Correct missing remoteport registration during link bounces
  lpfc: update driver version to 12.0.0.2

 drivers/scsi/lpfc/lpfc.h   |   9 +--
 drivers/scsi/lpfc/lpfc_attr.c  | 112 ++--
 drivers/scsi/lpfc/lpfc_ct.c|  10 +++
 drivers/scsi/lpfc/lpfc_debugfs.c   |  93 ---
 drivers/scsi/lpfc/lpfc_els.c   |   1 -
 drivers/scsi/lpfc/lpfc_hbadisc.c   |   4 -
 drivers/scsi/lpfc/lpfc_hw4.h   |  12 +++
 drivers/scsi/lpfc/lpfc_init.c  |  62 +++-
 drivers/scsi/lpfc/lpfc_nportdisc.c |  29 ++--
 drivers/scsi/lpfc/lpfc_nvme.c  | 146 +++--
 drivers/scsi/lpfc/lpfc_nvme.h  |  14 
 drivers/scsi/lpfc/lpfc_nvmet.h |   6 +-
 drivers/scsi/lpfc/lpfc_scsi.c  |  31 +++-
 drivers/scsi/lpfc/lpfc_sli.c   |  16 ++--
 drivers/scsi/lpfc/lpfc_sli4.h  |   1 +
 drivers/scsi/lpfc/lpfc_version.h   |   2 +-
 16 files changed, 378 insertions(+), 170 deletions(-)

-- 
2.13.1



[PATCH v2 01/13] lpfc: Fix multiple PRLI completion error path

2018-04-09 Thread James Smart
Nodelist entry for SCSI array ends up in UNMAPPED state. This is
due to illegal discovery State machine transition because of two
PRLIs and the first one failing with LS_RJT. Also, the error path
was designed assuming the PRLIs complete in the order they were
sent, FCP first, then NVME. In a failing case, the array thinks
about the first PRLI (FCP), but issues LS_RJT for the 2nd PRLI
immediately.

Fix PRLI completion error path for the ordering expectation.
Ensure the discovery state machine update is not set until all
outstanding PRLIs are complete.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
Reviewed-by: Hannes Reinecke 
---
 drivers/scsi/lpfc/lpfc_nportdisc.c | 29 ++---
 1 file changed, 6 insertions(+), 23 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc_nportdisc.c 
b/drivers/scsi/lpfc/lpfc_nportdisc.c
index 022060636ae1..e790c0bc64fc 100644
--- a/drivers/scsi/lpfc/lpfc_nportdisc.c
+++ b/drivers/scsi/lpfc/lpfc_nportdisc.c
@@ -1936,31 +1936,14 @@ lpfc_cmpl_prli_prli_issue(struct lpfc_vport *vport, 
struct lpfc_nodelist *ndlp,
goto out;
}
 
-   /* When the rport rejected the FCP PRLI as unsupported.
-* This should only happen in Pt2Pt so an NVME PRLI
-* should be outstanding still.
-*/
-   if (npr && ndlp->nlp_flag & NLP_FCP_PRLI_RJT) {
+   /* Adjust the nlp_type accordingly if the PRLI failed */
+   if (npr)
ndlp->nlp_fc4_type &= ~NLP_FC4_FCP;
-   goto out_err;
-   }
-
-   /* The LS Req had some error.  Don't let this be a
-* target.
-*/
-   if ((ndlp->fc4_prli_sent == 1) &&
-   (ndlp->nlp_state == NLP_STE_PRLI_ISSUE) &&
-   (ndlp->nlp_type & (NLP_FCP_TARGET | NLP_FCP_INITIATOR)))
-   /* The FCP PRLI completed successfully but
-* the NVME PRLI failed.  Since they are sent in
-* succession, allow the FCP to complete.
-*/
-   goto out_err;
+   if (nvpr)
+   ndlp->nlp_fc4_type &= ~NLP_FC4_NVME;
 
-   ndlp->nlp_prev_state = NLP_STE_PRLI_ISSUE;
-   ndlp->nlp_type |= NLP_FCP_INITIATOR;
-   lpfc_nlp_set_state(vport, ndlp, NLP_STE_UNMAPPED_NODE);
-   return ndlp->nlp_state;
+   /* We can't set the DSM state till BOTH PRLIs complete */
+   goto out_err;
}
 
if (npr && (npr->acceptRspCode == PRLI_REQ_EXECUTED) &&
-- 
2.13.1



Re: [PATCH 12/14] lpfc: Fix create_association oops on unloading LPFC driver

2018-04-09 Thread James Smart

On 4/9/2018 2:14 PM, James Smart wrote:

On 4/9/2018 1:03 AM, Hannes Reinecke wrote:

On Sat,  7 Apr 2018 11:30:24 -0700
James Smart  wrote:


Driver unload isn't waiting for all outstanding nvme associations
to terminate before clearing structures. In particular, it did not
set dev_loss_tmo to 0 such that all associations are immediately
terminated. Thus the transport would enter reconnect timeouts and
reattempt reconnect to an nvme controller. The call makes a call
into the driver to create hw queues for the controller which causes
a NULL pointer reference.

Correct by changing the teardown process to change all dev_loss_tmo
timeouts to 0 so that they are immediate. Now the teardown process
initiates, the remote ports unregistered and delete callback made,
and as the assocations are immediate upon remoteport unregister, the
transport will not longer invoke the callbacks for a new controller.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
  drivers/scsi/lpfc/lpfc_hbadisc.c | 20 
  1 file changed, 20 insertions(+)



Hmm. This seems to be a very circumspect way of deleting all
outstanding I/O...
Is there any guarantee that nvme_fc_set_remoteport_devloss() will
return only after all callbacks are invoked?


well roundabout - I agree.   No, the set_remoteport_devloss won't make 
the guarantee, but the unregister_remoteport and the wait for the 
remoteport_delete call will.


And as I look deeper at this failure scenario, I'm starting to believe 
that the actual problem was the missed unregister_remoteport that was 
one of the other problems corrected in the patch set - by patch 12 or 14.


sorry - meant 11 or 13.



I'm going to repost, pulling this patch from the set. We'll retest and 
if still needed, we'll fix it in the next patch set.


-- james





Re: [PATCH 12/14] lpfc: Fix create_association oops on unloading LPFC driver

2018-04-09 Thread James Smart

On 4/9/2018 1:03 AM, Hannes Reinecke wrote:

On Sat,  7 Apr 2018 11:30:24 -0700
James Smart  wrote:


Driver unload isn't waiting for all outstanding nvme associations
to terminate before clearing structures. In particular, it did not
set dev_loss_tmo to 0 such that all associations are immediately
terminated. Thus the transport would enter reconnect timeouts and
reattempt reconnect to an nvme controller. The call makes a call
into the driver to create hw queues for the controller which causes
a NULL pointer reference.

Correct by changing the teardown process to change all dev_loss_tmo
timeouts to 0 so that they are immediate. Now the teardown process
initiates, the remote ports unregistered and delete callback made,
and as the assocations are immediate upon remoteport unregister, the
transport will not longer invoke the callbacks for a new controller.

Signed-off-by: Dick Kennedy 
Signed-off-by: James Smart 
---
  drivers/scsi/lpfc/lpfc_hbadisc.c | 20 
  1 file changed, 20 insertions(+)



Hmm. This seems to be a very circumspect way of deleting all
outstanding I/O...
Is there any guarantee that nvme_fc_set_remoteport_devloss() will
return only after all callbacks are invoked?


well roundabout - I agree.   No, the set_remoteport_devloss won't make 
the guarantee, but the unregister_remoteport and the wait for the 
remoteport_delete call will.


And as I look deeper at this failure scenario, I'm starting to believe 
that the actual problem was the missed unregister_remoteport that was 
one of the other problems corrected in the patch set - by patch 12 or 14.


I'm going to repost, pulling this patch from the set. We'll retest and 
if still needed, we'll fix it in the next patch set.


-- james



Re: [PATCH 01/10] staging: fnic2 add initialization

2018-04-09 Thread Martin K. Petersen

Greg,

>> If you think that this driver doesn't belong in the drivers/staging
>> community, we are happy to explore getting the driver fully ready on
>> our side and getting it into the "proper" place.
>
> I'll take anything in staging as long as it has the correct license and
> builds, that's not an issue :)  But I do want to get agreement from the
> SCSI maintainers that this is ok to have in this part of the kernel as
> sometimes it can cause merge issues if there are core api changes.

This is the first I hear of fnic2.

My initial questions are: Why is a new driver necessary? Why can't the
existing fnic driver be extended? And if it can't, what can be shared
between the two drivers?

A good place to have that discussion would be on linux-scsi...

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Kees Cook
On Mon, Apr 9, 2018 at 12:02 PM, Oleksandr Natalenko
 wrote:
>
> Hi.
>
> (fancy details for linux-block and BFQ people go below)
>
> 09.04.2018 20:32, Kees Cook wrote:
>>
>> Ah, this detail I didn't have. I've changed my environment to
>>
>> build with:
>>
>> CONFIG_BLK_MQ_PCI=y
>> CONFIG_BLK_MQ_VIRTIO=y
>> CONFIG_IOSCHED_BFQ=y
>>
>> boot with scsi_mod.use_blk_mq=1
>>
>> and select BFQ in the scheduler:
>>
>> # cat /sys/block/sd?/queue/scheduler
>> mq-deadline kyber [bfq] none
>> mq-deadline kyber [bfq] none
>>
>> Even with this, I'm not seeing anything yet...
>
>
> Thanks for looking into it anyway. I was experimenting today a little bit, 
> and for me it looks like setting queue_depth and nr_requests to minimal 
> values speeds up the reproducing. Could you please try it too? Something like:
>
> echo 1 | tee /sys/block/sd*/queue/nr_requests

I can't get this below "4".

> echo 1 | tee /sys/block/sd*/device/queue_depth

I've got this now too.

> Also, now I have a more solid proof that this is related to I/O scheduling.
>
> I was hammering my VM, and after a couple of usercopy warnings/bugs I can 
> reliably trigger I/O hang. I was able to obtain the stack traces of tasks in 
> D state. Listing them here below. dmcrypt_write:

Ah! dm-crypt too. I'll see if I can get that added easily to my tests.

> ===
> [ 1615.409622] dmcrypt_write   D0   236  2 0x8000
> [ 1615.413422] Call Trace:
> [ 1615.415428]  ? __schedule+0x336/0xf40
> [ 1615.417824]  ? blk_mq_sched_dispatch_requests+0x117/0x190
> [ 1615.421423]  ? __sbitmap_get_word+0x2a/0x80
> [ 1615.424202]  schedule+0x32/0xc0
> [ 1615.426521]  io_schedule+0x12/0x40
> [ 1615.432414]  blk_mq_get_tag+0x181/0x2a0
> [ 1615.434881]  ? elv_merge+0x79/0xe0
> [ 1615.437447]  ? wait_woken+0x80/0x80
> [ 1615.439553]  blk_mq_get_request+0xf9/0x400
> [ 1615.444653]  blk_mq_make_request+0x10b/0x640
> [ 1615.448025]  generic_make_request+0x124/0x2d0
> [ 1615.450716]  ? raid10_unplug+0xfb/0x180 [raid10]
> [ 1615.454069]  raid10_unplug+0xfb/0x180 [raid10]
> [ 1615.456729]  blk_flush_plug_list+0xc1/0x250
> [ 1615.460276]  blk_finish_plug+0x27/0x40
> [ 1615.464103]  dmcrypt_write+0x233/0x240 [dm_crypt]
> [ 1615.467443]  ? wake_up_process+0x20/0x20
> [ 1615.470845]  ? crypt_iv_essiv_dtr+0x60/0x60 [dm_crypt]
> [ 1615.475272]  ? kthread+0x113/0x130
> [ 1615.477652]  kthread+0x113/0x130
> [ 1615.480567]  ? kthread_create_on_node+0x70/0x70
> [ 1615.483268]  ret_from_fork+0x35/0x40
> ===
>
> One of XFS threads, too:

And XFS! You love your corner cases. ;)

>
> ===
> [ 1616.133298] xfsaild/dm-7D0   316  2 0x8000
> [ 1616.136679] Call Trace:
> [ 1616.138845]  ? __schedule+0x336/0xf40
> [ 1616.141581]  ? preempt_count_add+0x68/0xa0
> [ 1616.147214]  ? _raw_spin_unlock+0x16/0x30
> [ 1616.149813]  ? _raw_spin_unlock_irqrestore+0x20/0x40
> [ 1616.152478]  ? try_to_del_timer_sync+0x4d/0x80
> [ 1616.154734]  schedule+0x32/0xc0
> [ 1616.156579]  _xfs_log_force+0x146/0x290 [xfs]
> [ 1616.159322]  ? wake_up_process+0x20/0x20
> [ 1616.162175]  xfsaild+0x1a9/0x820 [xfs]
> [ 1616.164695]  ? xfs_trans_ail_cursor_first+0x80/0x80 [xfs]
> [ 1616.167567]  ? kthread+0x113/0x130
> [ 1616.169722]  kthread+0x113/0x130
> [ 1616.171908]  ? kthread_create_on_node+0x70/0x70
> [ 1616.174073]  ? do_syscall_64+0x74/0x190
> [ 1616.179008]  ? SyS_exit_group+0x10/0x10
> [ 1616.182306]  ret_from_fork+0x35/0x40
> ===
>
> journald is another victim:
>
> ===
> [ 1616.184343] systemd-journal D0   354  1 0x0104
> [ 1616.187282] Call Trace:
> [ 1616.189464]  ? __schedule+0x336/0xf40
> [ 1616.191781]  ? call_function_single_interrupt+0xa/0x20
> [ 1616.194788]  ? _raw_spin_lock_irqsave+0x25/0x50
> [ 1616.197592]  schedule+0x32/0xc0
> [ 1616.200171]  schedule_timeout+0x202/0x470
> [ 1616.202851]  ? preempt_count_add+0x49/0xa0
> [ 1616.206227]  wait_for_common+0xbb/0x180
> [ 1616.209877]  ? wake_up_process+0x20/0x20
> [ 1616.212511]  do_coredump+0x335/0xea0
> [ 1616.214861]  ? schedule+0x3c/0xc0
> [ 1616.216775]  ? futex_wait_queue_me+0xbb/0x110
> [ 1616.218894]  ? _raw_spin_unlock+0x16/0x30
> [ 1616.220868]  ? futex_wait+0x143/0x240
> [ 1616.223450]  get_signal+0x250/0x5c0
> [ 1616.225965]  do_signal+0x36/0x610
> [ 1616.228246]  ? __seccomp_filter+0x3b/0x260
> [ 1616.231000]  ? __check_object_size+0x9f/0x1a0
> [ 1616.233716]  exit_to_usermode_loop+0x85/0xa0
> [ 1616.238413]  do_syscall_64+0x18b/0x190
> [ 1616.240798]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> [ 1616.244401] RIP: 0033:0x7f78fc53e45d
> [ 1616.246690] RSP: 002b:7ffd40330d20 EFLAGS: 0246 ORIG_RAX: 
> 00ca
> [ 1616.251199] RAX: fe00 RBX: 7f78f7806700 RCX: 
> 7f78fc53e45d
> [ 1616.254817] RDX: 04cd RSI:  RDI: 
> 7f78f78069d0
> [ 1616.258410] RBP: 7ffd40330d20 R08: 00ca R09: 
> 7f78f78069d0
> [ 1616.261813] R10:  R11: 0246 R12: 
> 
> [ 1616.265065] R13: 

Re: [PATCH 1/1] scsi/ufs: qcom: Don't enable PHY_QCOM_UFS by default

2018-04-09 Thread Bjorn Andersson
On Mon 09 Apr 10:38 PDT 2018, Vivek Gautam wrote:
> On 4/9/2018 10:21 PM, Bjorn Andersson wrote:
> > On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote:
[..]
> > > diff --git a/include/linux/phy/phy-qcom-ufs.h 
> > > b/include/linux/phy/phy-qcom-ufs.h
> > > index 0a2c18a9771d..1388c2a2965e 100644
> > > --- a/include/linux/phy/phy-qcom-ufs.h
> > > +++ b/include/linux/phy/phy-qcom-ufs.h
> > > @@ -31,8 +31,21 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy *phy);
> > >*/
> > >   void ufs_qcom_phy_disable_dev_ref_clk(struct phy *phy);
> > > +#if IS_ENABLED(CONFIG_PHY_QCOM_UFS)
> > >   int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 tx_lanes);
> > >   void ufs_qcom_phy_save_controller_version(struct phy *phy,
> > > - u8 major, u16 minor, u16 step);
> > > +   u8 major, u16 minor, u16 step);
> > > +#else
> > > +static inline int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 
> > > tx_lanes)
> > > +{
> > > + return -ENOSYS;
> > > +}
> > > +
> > > +static inline void ufs_qcom_phy_save_controller_version(struct phy *phy,
> > > + u8 major, u16 minor,
> > > + u16 step)
> > > +{
> > > +}
> > > +#endif /* PHY_QCOM_UFS */
> > What's the timeline for getting rid of the references to these
> > functions? I presume that code depending on these being here will
> > compile but won't actually work?
> 
> Yes, these inline definitions are just to keep ufs-qcom happy with the
> direct
> calls that it makes to these functions.
> As you would know these couple of functions are just used by the 20nm phy.
> However, we don't have any platform yet in the upstream that enables this
> phy.
> I am hoping that we will eventually get rid of these functions when we
> further
> clean up ufs-qcom driver.
> 

I see, but that means that we're calling this function with a struct phy
that might not be a struct ufs_qcom_phy and as such a defconfig with
both enabled will have undefined outcome for the migrated phys.

In particular we do expect that the same kernel will boot on db820c and
sdm845-mtp, so we will have to enable support for the 14nm & 20nm phy
driver (and we don't want random crashes because someone happened to
enable it).


So either we add the 10nm support to the existing driver or I think we
should migrate, at least, the 14nm support to the QMP driver (and mark
the remaining 20nm BROKEN for now).

Regardless of the path chosen this should be cleaned up to the point
where all three phys are supported.

Regards,
Bjorn


Re: [PATCH 1/2] scsi: ufs: Add UFS platform driver for Cadence UFS

2018-04-09 Thread Rob Herring
On Wed, Mar 28, 2018 at 11:25:34AM +, Janek Kotas wrote:
> This patch adds a device tree platform
> driver description for Cadence UFS Controller.

You have exactly the same subject for both patches. Don't do that. For 
bindings, the preferred subject prefix is "dt-bindings: ufs: ".

> 
> Signed-off-by: Jan Kotas 
> ---
>  .../devicetree/bindings/ufs/cdns-ufs-pltfrm.txt|   31 
> 
>  1 files changed, 31 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/ufs/cdns-ufs-pltfrm.txt
> 
> diff --git a/Documentation/devicetree/bindings/ufs/cdns-ufs-pltfrm.txt 
> b/Documentation/devicetree/bindings/ufs/cdns-ufs-pltfrm.txt
> new file mode 100644
> index 000..d10229d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ufs/cdns-ufs-pltfrm.txt

rename to cdns,ufshc.txt

> @@ -0,0 +1,31 @@
> +* Cadence Universal Flash Storage (UFS) Controller
> +
> +UFS nodes are defined to describe on-chip UFS host controllers.
> +Each UFS controller instance should have its own node.
> +
> +Required properties:
> +- compatible : compatible list, contains the following controller:
> + "cdns,ufshc"
> +   complemented with the JEDEC version:
> + "jedec,ufs-2.0"
> +
> +- reg: registers mapping
> +- interrupts : interrupts mapping

How many?

> +- clocks : List of phandle and clock specifier pairs.
> +- clock-names: List of clock input name strings sorted in the same
> +   order as the clocks property. "core_clk" is mandatory.

"_clk" is redundant.

Really only one clock for the block? No clock from the PHY? No bus 
clock?

> +- freq-table-hz  : Array of  operating frequencies stored in 
> the same
> +   order as the clocks property. If this property is not
> +   defined or a value in the array is "0" then it is assumed
> +   that the frequency is set by the parent clock or a
> +   fixed rate clock source.

The 'assigned-clocks' property and friends should be able to handle 
this.

> +
> +Example:
> + ufs@fd03 {
> + compatible = "cdns,ufshc", "jedec,ufs-2.0";
> + reg = <0xfd03 0x1>;
> + interrupts = <0 1 0>;
> + freq-table-hz = <0 0>;
> + clocks = <_core_clk 0>;
> + clock-names = "core_clk";
> + };
> -- 
> 1.7.1


Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Oleksandr Natalenko

Hi.

(fancy details for linux-block and BFQ people go below)

09.04.2018 20:32, Kees Cook wrote:

Ah, this detail I didn't have. I've changed my environment to

build with:

CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_IOSCHED_BFQ=y

boot with scsi_mod.use_blk_mq=1

and select BFQ in the scheduler:

# cat /sys/block/sd?/queue/scheduler
mq-deadline kyber [bfq] none
mq-deadline kyber [bfq] none

Even with this, I'm not seeing anything yet...


Thanks for looking into it anyway. I was experimenting today a little 
bit, and for me it looks like setting queue_depth and nr_requests to 
minimal values speeds up the reproducing. Could you please try it too? 
Something like:


echo 1 | tee /sys/block/sd*/queue/nr_requests
echo 1 | tee /sys/block/sd*/device/queue_depth

Also, now I have a more solid proof that this is related to I/O 
scheduling.


I was hammering my VM, and after a couple of usercopy warnings/bugs I 
can reliably trigger I/O hang. I was able to obtain the stack traces of 
tasks in D state. Listing them here below. dmcrypt_write:


===
[ 1615.409622] dmcrypt_write   D0   236  2 0x8000
[ 1615.413422] Call Trace:
[ 1615.415428]  ? __schedule+0x336/0xf40
[ 1615.417824]  ? blk_mq_sched_dispatch_requests+0x117/0x190
[ 1615.421423]  ? __sbitmap_get_word+0x2a/0x80
[ 1615.424202]  schedule+0x32/0xc0
[ 1615.426521]  io_schedule+0x12/0x40
[ 1615.432414]  blk_mq_get_tag+0x181/0x2a0
[ 1615.434881]  ? elv_merge+0x79/0xe0
[ 1615.437447]  ? wait_woken+0x80/0x80
[ 1615.439553]  blk_mq_get_request+0xf9/0x400
[ 1615.444653]  blk_mq_make_request+0x10b/0x640
[ 1615.448025]  generic_make_request+0x124/0x2d0
[ 1615.450716]  ? raid10_unplug+0xfb/0x180 [raid10]
[ 1615.454069]  raid10_unplug+0xfb/0x180 [raid10]
[ 1615.456729]  blk_flush_plug_list+0xc1/0x250
[ 1615.460276]  blk_finish_plug+0x27/0x40
[ 1615.464103]  dmcrypt_write+0x233/0x240 [dm_crypt]
[ 1615.467443]  ? wake_up_process+0x20/0x20
[ 1615.470845]  ? crypt_iv_essiv_dtr+0x60/0x60 [dm_crypt]
[ 1615.475272]  ? kthread+0x113/0x130
[ 1615.477652]  kthread+0x113/0x130
[ 1615.480567]  ? kthread_create_on_node+0x70/0x70
[ 1615.483268]  ret_from_fork+0x35/0x40
===

One of XFS threads, too:

===
[ 1616.133298] xfsaild/dm-7D0   316  2 0x8000
[ 1616.136679] Call Trace:
[ 1616.138845]  ? __schedule+0x336/0xf40
[ 1616.141581]  ? preempt_count_add+0x68/0xa0
[ 1616.147214]  ? _raw_spin_unlock+0x16/0x30
[ 1616.149813]  ? _raw_spin_unlock_irqrestore+0x20/0x40
[ 1616.152478]  ? try_to_del_timer_sync+0x4d/0x80
[ 1616.154734]  schedule+0x32/0xc0
[ 1616.156579]  _xfs_log_force+0x146/0x290 [xfs]
[ 1616.159322]  ? wake_up_process+0x20/0x20
[ 1616.162175]  xfsaild+0x1a9/0x820 [xfs]
[ 1616.164695]  ? xfs_trans_ail_cursor_first+0x80/0x80 [xfs]
[ 1616.167567]  ? kthread+0x113/0x130
[ 1616.169722]  kthread+0x113/0x130
[ 1616.171908]  ? kthread_create_on_node+0x70/0x70
[ 1616.174073]  ? do_syscall_64+0x74/0x190
[ 1616.179008]  ? SyS_exit_group+0x10/0x10
[ 1616.182306]  ret_from_fork+0x35/0x40
===

journald is another victim:

===
[ 1616.184343] systemd-journal D0   354  1 0x0104
[ 1616.187282] Call Trace:
[ 1616.189464]  ? __schedule+0x336/0xf40
[ 1616.191781]  ? call_function_single_interrupt+0xa/0x20
[ 1616.194788]  ? _raw_spin_lock_irqsave+0x25/0x50
[ 1616.197592]  schedule+0x32/0xc0
[ 1616.200171]  schedule_timeout+0x202/0x470
[ 1616.202851]  ? preempt_count_add+0x49/0xa0
[ 1616.206227]  wait_for_common+0xbb/0x180
[ 1616.209877]  ? wake_up_process+0x20/0x20
[ 1616.212511]  do_coredump+0x335/0xea0
[ 1616.214861]  ? schedule+0x3c/0xc0
[ 1616.216775]  ? futex_wait_queue_me+0xbb/0x110
[ 1616.218894]  ? _raw_spin_unlock+0x16/0x30
[ 1616.220868]  ? futex_wait+0x143/0x240
[ 1616.223450]  get_signal+0x250/0x5c0
[ 1616.225965]  do_signal+0x36/0x610
[ 1616.228246]  ? __seccomp_filter+0x3b/0x260
[ 1616.231000]  ? __check_object_size+0x9f/0x1a0
[ 1616.233716]  exit_to_usermode_loop+0x85/0xa0
[ 1616.238413]  do_syscall_64+0x18b/0x190
[ 1616.240798]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 1616.244401] RIP: 0033:0x7f78fc53e45d
[ 1616.246690] RSP: 002b:7ffd40330d20 EFLAGS: 0246 ORIG_RAX: 
00ca
[ 1616.251199] RAX: fe00 RBX: 7f78f7806700 RCX: 
7f78fc53e45d
[ 1616.254817] RDX: 04cd RSI:  RDI: 
7f78f78069d0
[ 1616.258410] RBP: 7ffd40330d20 R08: 00ca R09: 
7f78f78069d0
[ 1616.261813] R10:  R11: 0246 R12: 

[ 1616.265065] R13:  R14: 7f78fc95e8c0 R15: 
7f78f7806d28


[ 1616.272861] journal-offline D0  1229  1 0x0104
[ 1616.275856] Call Trace:
[ 1616.277396]  ? __schedule+0x336/0xf40
[ 1616.279258]  ? release_pages+0x192/0x3d0
[ 1616.282871]  schedule+0x32/0xc0
[ 1616.285218]  io_schedule+0x12/0x40
[ 1616.287267]  wait_on_page_bit+0xea/0x130
[ 1616.291084]  ? add_to_page_cache_lru+0xe0/0xe0
[ 1616.293898]  __filemap_fdatawait_range+0xbb/0x110
[ 1616.297391]  ? xen_swiotlb_init+0x85/0x4d0
[ 

Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Kees Cook
On Sun, Apr 8, 2018 at 12:07 PM, Oleksandr Natalenko
 wrote:
> So far, I wasn't able to trigger this with mq-deadline (or without blk-mq).
> Maybe, this has something to do with blk-mq+BFQ re-queuing, or it's just me
> not being persistent enough.

Ah, this detail I didn't have. I've changed my environment to

build with:

CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_IOSCHED_BFQ=y

boot with scsi_mod.use_blk_mq=1

and select BFQ in the scheduler:

# cat /sys/block/sd?/queue/scheduler
mq-deadline kyber [bfq] none
mq-deadline kyber [bfq] none

Even with this, I'm not seeing anything yet...

> It looks like this code path was re-written completely with 17cb960f29c2, but
> it went merged for the upcoming v4.17 only, and thus I haven't tried it yet.
>
> Kees took a brief look at it already: [1]. This is what smartctl does [2]
> (just a usual strace capture when the bug is not triggered).
>
> Christoph, do you have some idea on why this can happen?
>
> Thanks.
>
> Regards,
>   Oleksandr
>
> [1] https://marc.info/?l=linux-scsi=152287333013845=2
> [2] https://gist.github.com/pfactum/6f58f8891468aeba1ab2cc9f45668735

The thing I can't figure out is how req->sense is slipping forward in
(and even beyond!) the allocation.

-Kees

-- 
Kees Cook
Pixel Security


Re: [PATCH 1/1] scsi/ufs: qcom: Don't enable PHY_QCOM_UFS by default

2018-04-09 Thread Vivek Gautam

Hi Bjorn,


On 4/9/2018 10:21 PM, Bjorn Andersson wrote:

On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote:


While we try to transition from a separate ufs phy driver to a
more integrated qmp phy driver, don't let SCSI_UFS_QCOM to
enable PHY_QCOM_UFS config by default.
The users should enable this in their defconfigs.
Also add inline definitions for couple of functions -
a) ufs_qcom_phy_set_tx_lane_enable()
b) void ufs_qcom_phy_save_controller_version()
to enable clean build for SCSI_UFS_QCOM.

Signed-off-by: Vivek Gautam 
---
  drivers/scsi/ufs/Kconfig |  1 -
  include/linux/phy/phy-qcom-ufs.h | 15 ++-
  2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index e27b4d4e6ae2..7e8898b6eb67 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -91,7 +91,6 @@ config SCSI_UFS_DWC_TC_PLATFORM
  config SCSI_UFS_QCOM
tristate "QCOM specific hooks to UFS controller platform driver"
depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
-   select PHY_QCOM_UFS

As you're depending on function in the UFS phy, which can be compiled as
a module you might end up in a configuration where UFS_QCOM is builtin
and the PHY_QCOM_UFS is module, which will fail to link.

So you need to make this:

depends on PHY_QCOM_UFS || PHY_QCOM_UFS=n

In which case we say that if PHY_QCOM_UFS is a module UFS_QCOM must be a
module and if PHY_QCOM_UFS is not compiled in UFS_QCOM can be either
builtin or a module.


Thanks for reviewing. You are right. I was trying to test all possible
cases for the PHY_QCOM_UFS, and SCSI_UFS_QCOM configs, but clearly i missed
this case.
Will modify as suggested.


help
  This selects the QCOM specific additions to UFSHCD platform driver.
  UFS host on QCOM needs some vendor specific configuration before
diff --git a/include/linux/phy/phy-qcom-ufs.h b/include/linux/phy/phy-qcom-ufs.h
index 0a2c18a9771d..1388c2a2965e 100644
--- a/include/linux/phy/phy-qcom-ufs.h
+++ b/include/linux/phy/phy-qcom-ufs.h
@@ -31,8 +31,21 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy *phy);
   */
  void ufs_qcom_phy_disable_dev_ref_clk(struct phy *phy);
  
+#if IS_ENABLED(CONFIG_PHY_QCOM_UFS)

  int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 tx_lanes);
  void ufs_qcom_phy_save_controller_version(struct phy *phy,
-   u8 major, u16 minor, u16 step);
+ u8 major, u16 minor, u16 step);
+#else
+static inline int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 
tx_lanes)
+{
+   return -ENOSYS;
+}
+
+static inline void ufs_qcom_phy_save_controller_version(struct phy *phy,
+   u8 major, u16 minor,
+   u16 step)
+{
+}
+#endif /* PHY_QCOM_UFS */

What's the timeline for getting rid of the references to these
functions? I presume that code depending on these being here will
compile but won't actually work?


Yes, these inline definitions are just to keep ufs-qcom happy with the 
direct

calls that it makes to these functions.
As you would know these couple of functions are just used by the 20nm phy.
However, we don't have any platform yet in the upstream that enables 
this phy.
I am hoping that we will eventually get rid of these functions when we 
further

clean up ufs-qcom driver.

Best regards
Vivek


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




Re: [PATCH 1/1] scsi/ufs: qcom: Don't enable PHY_QCOM_UFS by default

2018-04-09 Thread Bjorn Andersson
On Mon 09 Apr 06:24 PDT 2018, Vivek Gautam wrote:

> While we try to transition from a separate ufs phy driver to a
> more integrated qmp phy driver, don't let SCSI_UFS_QCOM to
> enable PHY_QCOM_UFS config by default.
> The users should enable this in their defconfigs.
> Also add inline definitions for couple of functions -
> a) ufs_qcom_phy_set_tx_lane_enable()
> b) void ufs_qcom_phy_save_controller_version()
> to enable clean build for SCSI_UFS_QCOM.
> 
> Signed-off-by: Vivek Gautam 
> ---
>  drivers/scsi/ufs/Kconfig |  1 -
>  include/linux/phy/phy-qcom-ufs.h | 15 ++-
>  2 files changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index e27b4d4e6ae2..7e8898b6eb67 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -91,7 +91,6 @@ config SCSI_UFS_DWC_TC_PLATFORM
>  config SCSI_UFS_QCOM
>   tristate "QCOM specific hooks to UFS controller platform driver"
>   depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
> - select PHY_QCOM_UFS

As you're depending on function in the UFS phy, which can be compiled as
a module you might end up in a configuration where UFS_QCOM is builtin
and the PHY_QCOM_UFS is module, which will fail to link.

So you need to make this:

depends on PHY_QCOM_UFS || PHY_QCOM_UFS=n

In which case we say that if PHY_QCOM_UFS is a module UFS_QCOM must be a
module and if PHY_QCOM_UFS is not compiled in UFS_QCOM can be either
builtin or a module.

>   help
> This selects the QCOM specific additions to UFSHCD platform driver.
> UFS host on QCOM needs some vendor specific configuration before
> diff --git a/include/linux/phy/phy-qcom-ufs.h 
> b/include/linux/phy/phy-qcom-ufs.h
> index 0a2c18a9771d..1388c2a2965e 100644
> --- a/include/linux/phy/phy-qcom-ufs.h
> +++ b/include/linux/phy/phy-qcom-ufs.h
> @@ -31,8 +31,21 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy *phy);
>   */
>  void ufs_qcom_phy_disable_dev_ref_clk(struct phy *phy);
>  
> +#if IS_ENABLED(CONFIG_PHY_QCOM_UFS)
>  int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 tx_lanes);
>  void ufs_qcom_phy_save_controller_version(struct phy *phy,
> - u8 major, u16 minor, u16 step);
> +   u8 major, u16 minor, u16 step);
> +#else
> +static inline int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 
> tx_lanes)
> +{
> + return -ENOSYS;
> +}
> +
> +static inline void ufs_qcom_phy_save_controller_version(struct phy *phy,
> + u8 major, u16 minor,
> + u16 step)
> +{
> +}
> +#endif /* PHY_QCOM_UFS */

What's the timeline for getting rid of the references to these
functions? I presume that code depending on these being here will
compile but won't actually work?

Regards,
Bjorn


Re: Multi-Actuator SAS HDD First Look

2018-04-09 Thread Douglas Gilbert

On 2018-04-09 02:17 AM, Hannes Reinecke wrote:

On 04/09/2018 04:08 AM, Tim Walker wrote:

On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert  wrote:


On 2018-04-06 02:42 AM, Christoph Hellwig wrote:


On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:


Ah. Far better.
What about delegating FORMAT UNIT to the control LUN, and not
implementing it for the individual disk LUNs?
That would make an even stronger case for having a control LUN;
with that there wouldn't be any problem with having to synchronize
across LUNs etc.



It sounds to me like NVMe might be a much better model for this drive
than SCSI, btw :)



So you found a document that outlines NVMe's architecture! Could you
share the url (no marketing BS, please)?


And a serious question ... How would you map NVMe's (in Linux)
subsystem number, controller device minor number, CNTLID field
(Identify ctl response) and namespace id onto the SCSI subsystem's
h:c:t:l ?

Doug Gilbert



Hannes- yes, a drive system altering operation like FORMAT UNIT is
asking for a dedicated management port, as the NVMe folks apparently
felt. But what is the least painful endpoint type for LUN0?



I would probably use 'processor device' (ie type 3) as it's the least
defined, so you can do basically everything you like with it.
Possibly 'Enclosure Services' (type 0x0d) works, too, but then you have
to check with the SES spec if it allows the things you'd need.


Processor device type (0x3) please. Then you are only required to support
the mandatory commands in SPC and that is not many. And then nothing
precludes you from implementing Start Stop Unit, Sanitize and/or Format
Unit on it. And as I pointed out earlier, you could even throw in a
copy manager (see SPC). Also as far as I know Linux, FreeBSD and Windows
will leave a Processor device type LU alone and just have a SCSI
pass-through device attached to it, and that is exactly what you want.
By default only root/administrator can open those pass-through devices.

If you chose SES type (0xd) then the Linux kernel ses driver (and the
FreeBSD equivalent) would attempt to attach to it before the user space
could countermand it (as things stand). And SES additionally makes the
SEND DIAGNOSTIC and RECEIVE DIAGNOSTIC RESULTS commands mandatory and
at least one diagnostic page (0x0) mandatory. If it doesn't supply
any other SES dpages then those two drivers are going to get pretty
confused (which would be a good test for them). Also it could get
confusing from an administration point of view. I'm guessing many of
these Multi-Actuator SAS HDDs will end up in big enclosures. And
those enclosures most likely would present a SES device. Multiple dummy
enclosures within a real enclosure will look strange (especially as
SES already has a concept of a sub-enclosure).

Doug Gilbert




Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Oleksandr Natalenko

Hi.

09.04.2018 11:35, Christoph Hellwig wrote:

I really can't make sense of that report.


Sorry, I have nothing to add there so far, I just see the symptom of 
something going wrong in the ioctl code path that is invoked by 
smartctl, but I have no idea what's the minimal environment to reproduce 
it. I'll try to collect more info.



And I'm also curious why
you think 17cb960f29c2 should change anything for that code path.


Maybe, I've just mis-read that code.

Regards,
  Oleksandr


Re: [PATCH] scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION

2018-04-09 Thread Bart Van Assche
On Mon, 2018-04-09 at 14:39 +0200, Johannes Thumshirn wrote:
> Bart reports that in qla_isr.c's qla2x00_handle_dif_error we're
> wrongly shifting the SAM_STAT_CHECK_CONDITION by one instead of
> directly ORing it onto the SCSI command's result.

Reviewed-by: Bart Van Assche 




Re: [PATCH] scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION

2018-04-09 Thread Hannes Reinecke
On 04/09/2018 02:39 PM, Johannes Thumshirn wrote:
> Bart reports that in qla_isr.c's qla2x00_handle_dif_error we're
> wrongly shifting the SAM_STAT_CHECK_CONDITION by one instead of
> directly ORing it onto the SCSI command's result.
> 
> Signed-off-by: Johannes Thumshirn 
> Reported-by: Bart Van Assche 
> Cc: Himanshu Madhani 
> ---
>  drivers/scsi/qla2xxx/qla_isr.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 49d67e1d571f..ed6cdfea00b4 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -2195,7 +2195,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct 
> sts_entry_24xx *sts24)
>   0x10, 0x1);
>   set_driver_byte(cmd, DRIVER_SENSE);
>   set_host_byte(cmd, DID_ABORT);
> - cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
> + cmd->result |= SAM_STAT_CHECK_CONDITION;
>   return 1;
>   }
>  
> @@ -2205,7 +2205,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct 
> sts_entry_24xx *sts24)
>   0x10, 0x3);
>   set_driver_byte(cmd, DRIVER_SENSE);
>   set_host_byte(cmd, DID_ABORT);
> - cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
> + cmd->result |= SAM_STAT_CHECK_CONDITION;
>   return 1;
>   }
>  
> @@ -2215,7 +2215,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct 
> sts_entry_24xx *sts24)
>   0x10, 0x2);
>   set_driver_byte(cmd, DRIVER_SENSE);
>   set_host_byte(cmd, DID_ABORT);
> - cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
> + cmd->result |= SAM_STAT_CHECK_CONDITION;
>   return 1;
>   }
>  
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


[PATCH 1/1] scsi/ufs: qcom: Don't enable PHY_QCOM_UFS by default

2018-04-09 Thread Vivek Gautam
While we try to transition from a separate ufs phy driver to a
more integrated qmp phy driver, don't let SCSI_UFS_QCOM to
enable PHY_QCOM_UFS config by default.
The users should enable this in their defconfigs.
Also add inline definitions for couple of functions -
a) ufs_qcom_phy_set_tx_lane_enable()
b) void ufs_qcom_phy_save_controller_version()
to enable clean build for SCSI_UFS_QCOM.

Signed-off-by: Vivek Gautam 
---
 drivers/scsi/ufs/Kconfig |  1 -
 include/linux/phy/phy-qcom-ufs.h | 15 ++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index e27b4d4e6ae2..7e8898b6eb67 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -91,7 +91,6 @@ config SCSI_UFS_DWC_TC_PLATFORM
 config SCSI_UFS_QCOM
tristate "QCOM specific hooks to UFS controller platform driver"
depends on SCSI_UFSHCD_PLATFORM && ARCH_QCOM
-   select PHY_QCOM_UFS
help
  This selects the QCOM specific additions to UFSHCD platform driver.
  UFS host on QCOM needs some vendor specific configuration before
diff --git a/include/linux/phy/phy-qcom-ufs.h b/include/linux/phy/phy-qcom-ufs.h
index 0a2c18a9771d..1388c2a2965e 100644
--- a/include/linux/phy/phy-qcom-ufs.h
+++ b/include/linux/phy/phy-qcom-ufs.h
@@ -31,8 +31,21 @@ void ufs_qcom_phy_enable_dev_ref_clk(struct phy *phy);
  */
 void ufs_qcom_phy_disable_dev_ref_clk(struct phy *phy);
 
+#if IS_ENABLED(CONFIG_PHY_QCOM_UFS)
 int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 tx_lanes);
 void ufs_qcom_phy_save_controller_version(struct phy *phy,
-   u8 major, u16 minor, u16 step);
+ u8 major, u16 minor, u16 step);
+#else
+static inline int ufs_qcom_phy_set_tx_lane_enable(struct phy *phy, u32 
tx_lanes)
+{
+   return -ENOSYS;
+}
+
+static inline void ufs_qcom_phy_save_controller_version(struct phy *phy,
+   u8 major, u16 minor,
+   u16 step)
+{
+}
+#endif /* PHY_QCOM_UFS */
 
 #endif /* PHY_QCOM_UFS_H_ */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



[PATCH] scsi: qla2xxx: Correct setting of SAM_STAT_CHECK_CONDITION

2018-04-09 Thread Johannes Thumshirn
Bart reports that in qla_isr.c's qla2x00_handle_dif_error we're
wrongly shifting the SAM_STAT_CHECK_CONDITION by one instead of
directly ORing it onto the SCSI command's result.

Signed-off-by: Johannes Thumshirn 
Reported-by: Bart Van Assche 
Cc: Himanshu Madhani 
---
 drivers/scsi/qla2xxx/qla_isr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 49d67e1d571f..ed6cdfea00b4 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2195,7 +2195,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
0x10, 0x1);
set_driver_byte(cmd, DRIVER_SENSE);
set_host_byte(cmd, DID_ABORT);
-   cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
+   cmd->result |= SAM_STAT_CHECK_CONDITION;
return 1;
}
 
@@ -2205,7 +2205,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
0x10, 0x3);
set_driver_byte(cmd, DRIVER_SENSE);
set_host_byte(cmd, DID_ABORT);
-   cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
+   cmd->result |= SAM_STAT_CHECK_CONDITION;
return 1;
}
 
@@ -2215,7 +2215,7 @@ qla2x00_handle_dif_error(srb_t *sp, struct sts_entry_24xx 
*sts24)
0x10, 0x2);
set_driver_byte(cmd, DRIVER_SENSE);
set_host_byte(cmd, DID_ABORT);
-   cmd->result |= SAM_STAT_CHECK_CONDITION << 1;
+   cmd->result |= SAM_STAT_CHECK_CONDITION;
return 1;
}
 
-- 
2.16.2



[PATCH v2] qla2xxx: correctly shift host byte

2018-04-09 Thread Johannes Thumshirn
The SCSI host byte has to be shifted by 16 not 6.

As Bart pointed out this patch does not change any functionality
because DID_OK == 0, but a wrong shift is irritating for the reviewer.

Signed-off-by: Johannes Thumshirn 
Reviewed-by: Bart Van Assche 
---
Changes to v1:
* Add Bart's review remark, that I'm not changing actual functionality
  as DID_OK == 0

 drivers/scsi/qla2xxx/qla_isr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 89f93ebd819d..49d67e1d571f 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2368,7 +2368,7 @@ qla25xx_process_bidir_status_iocb(scsi_qla_host_t *vha, 
void *pkt,
bsg_job->reply_len = sizeof(struct fc_bsg_reply);
/* Always return DID_OK, bsg will send the vendor specific response
 * in this case only */
-   sp->done(sp, DID_OK << 6);
+   sp->done(sp, DID_OK << 16);
 
 }
 
-- 
2.16.2



Re: [PATCH] qla2xxx: correctly shift host byte

2018-04-09 Thread Johannes Thumshirn
On Fri, Apr 06, 2018 at 03:33:30PM +, Bart Van Assche wrote:
> On Fri, 2018-04-06 at 09:52 +0200, Johannes Thumshirn wrote:
> > The host byte has to be shifted by 16 not 6.
> > 
> > Signed-off-by: Johannes Thumshirn 
> > ---
> >  drivers/scsi/qla2xxx/qla_isr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> > index 89f93ebd819d..49d67e1d571f 100644
> > --- a/drivers/scsi/qla2xxx/qla_isr.c
> > +++ b/drivers/scsi/qla2xxx/qla_isr.c
> > @@ -2368,7 +2368,7 @@ qla25xx_process_bidir_status_iocb(scsi_qla_host_t 
> > *vha, void *pkt,
> > bsg_job->reply_len = sizeof(struct fc_bsg_reply);
> > /* Always return DID_OK, bsg will send the vendor specific response
> >  * in this case only */
> > -   sp->done(sp, DID_OK << 6);
> > +   sp->done(sp, DID_OK << 16);
> >  
> >  }
> 
> Hello Johannes,
> 
> Had you noticed the following statements? I think the "<< 1" should be removed
> from these statements.
> 
> $ git grep 'SAM_STAT.*<< 1'
> drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= 
> SAM_STAT_CHECK_CONDITION << 1;
> drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= 
> SAM_STAT_CHECK_CONDITION << 1;
> drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= 
> SAM_STAT_CHECK_CONDITION << 1;

Thanks for the heads up, but this will be a separate patch.

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


Re: [PATCH] qla2xxx: correctly shift host byte

2018-04-09 Thread Johannes Thumshirn
On Fri, Apr 06, 2018 at 03:01:20PM +, Bart Van Assche wrote:
> Please mention in the description of this patch that this patch does not
> change any functionality because DID_OK == 0. Anyway:
> 
> Reviewed-by: Bart Van Assche 

I'll do. Thanks for the review.
-- 
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


Re: [PATCH v3 0/3] Report all request failures again to user space

2018-04-09 Thread Johannes Thumshirn
On Fri, Apr 06, 2018 at 02:59:16PM +, Bart Van Assche wrote:
> On Fri, 2018-04-06 at 09:45 +0200, Johannes Thumshirn wrote:
> > On 05/04/18 19:49, Martin K. Petersen wrote:
> > > Longer term I'd really like to see the command result integer
> > > host/driver/msg/status stuff cleaned up. It's super arcane and the
> > > associated naming schemes make it a very error-prone interface.
> > > 
> > 
> > I did start a series [1] for this but than got distracted by more urgent
> > things. I can pick it up again I think.
> > 
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=iscsi_DID_REQUEUE
> 
> Hello Johannes,
> 
> Since modifying how SCSI results are communicated from SCSI LLDs to the SCSI
> core requires to touch all SCSI LLDs, please consider to include the following
> changes in your patch series:
> - Remove the deprecated SCSI status codes (GOOD, CHECK_CONDITION, etc.) and
>   use the SAM_STAT_* symbolic names instead.

I'll have a look, thanks for the heads up.

> - Ensure that assigning an int to scsi_cmnd.result triggers a compiler error.
>   There is code in the Linux kernel that mixes traditional error codes (-EIO)
>   with the SCSI result codes (DID_ERROR << 16). I think most of that code is
>   buggy and that it should be fixed. Changing the type of scsi_cmnd.result is
>   one way to find such code. How about something like the following (untested)
>   patch?

I'll give it a shot.

> 
> diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
> index cb85eddb47ea..27f1c347f0ea 100644
> --- a/include/scsi/scsi.h
> +++ b/include/scsi/scsi.h
> @@ -18,6 +18,27 @@ enum scsi_timeouts {
>   SCSI_DEFAULT_EH_TIMEOUT = 10 * HZ,
>  };
>  
> +/*
> + * Note: .result is signed because SCSI LLDs store a SCSI result in
> + * .result while the bsg driver stores a negative error code in .result. 
> + */
> +typedef union {
> + s32 result;
> + struct {
> +#if defined(__BIG_ENDIAN)
> + u8  driver_byte;
> + u8  host_byte;
> + u8  msg_byte;
> + u8  status_byte;
> +#elif defined(__LITTLE_ENDIAN)
> + u8  status_byte;
> + u8  msg_byte;
> + u8  host_byte;
> + u8  driver_byte;
> +#endif
> + };
> +} scsi_result;
> +
>  /*
>   * DIX-capable adapters effectively support infinite chaining for the
>   * protection information scatterlist
> @@ -38,8 +59,10 @@ enum scsi_timeouts {
>   * This returns true for known good conditions that may be treated as
>   * command completed normally
>   */
> -static inline int scsi_status_is_good(int status)
> +static inline int scsi_status_is_good(scsi_result result)
>  {
> + u8 status = result.status_byte;
> +
>   /*
>* FIXME: bit0 is listed as reserved in SCSI-2, but is
>* significant in SCSI-3.  For now, we follow the SCSI-2
> @@ -205,10 +228,10 @@ static inline int scsi_is_wlun(u64 lun)
>   *  host_byte   = set by low-level driver to indicate status.
>   *  driver_byte = set by mid-level.
>   */
> -#define status_byte(result) (((result) >> 1) & 0x7f)
> -#define msg_byte(result)(((result) >> 8) & 0xff)
> -#define host_byte(result)   (((result) >> 16) & 0xff)
> -#define driver_byte(result) (((result) >> 24) & 0xff)
> +#define status_byte(result) ((result).status_byte >> 1)
> +#define msg_byte(result)((result).msg_byte)
> +#define host_byte(result)   ((result).host_byte)
> +#define driver_byte(result) ((result).driver_byte)
>  
>  #define sense_class(sense)  (((sense) >> 4) & 0x7)
>  #define sense_error(sense)  ((sense) & 0xf)
> diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
> index 2280b2351739..cbc5df948dd3 100644
> --- a/include/scsi/scsi_cmnd.h
> +++ b/include/scsi/scsi_cmnd.h
> @@ -144,7 +144,7 @@ struct scsi_cmnd {
>* obtained by scsi_malloc is guaranteed
>* to be at an address < 16Mb). */
>  
> - int result; /* Status code from lower level driver */
> + scsi_result result; /* Status code from lower level driver */
>   int flags;  /* Command flags */
>  
>   unsigned char tag;  /* SCSI-II queued command tag */
> 
> Bart.

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


[PATCH] tcmu: fix error resetting qfull_time_out to default

2018-04-09 Thread Prasanna Kumar Kalever
Problem:
---
$ cat /sys/kernel/config/target/core/user_0/block/attrib/qfull_time_out
-1

$ echo "-1" > /sys/kernel/config/target/core/user_0/block/attrib/qfull_time_out
-bash: echo: write error: Invalid argument

Fix:
---
This patch will help reset qfull_time_out to its default i.e. qfull_time_out=-1

Signed-off-by: Prasanna Kumar Kalever 
---
 drivers/target/target_core_user.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/target/target_core_user.c 
b/drivers/target/target_core_user.c
index 4ad89ea71a70..4f26bdc3d1dc 100644
--- a/drivers/target/target_core_user.c
+++ b/drivers/target/target_core_user.c
@@ -2121,6 +2121,8 @@ static ssize_t tcmu_qfull_time_out_store(struct 
config_item *item,
 
if (val >= 0) {
udev->qfull_time_out = val * MSEC_PER_SEC;
+   } else if (val == -1) {
+   udev->qfull_time_out = val;
} else {
printk(KERN_ERR "Invalid qfull timeout value %d\n", val);
return -EINVAL;
-- 
2.14.3



[PATCH v2 11/14] mpt3sas: Update MPI Headers

2018-04-09 Thread Chaitra P B
Update MPI Files to support protocol level reset for NVMe device.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpi/mpi2.h  |  9 ++---
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 30 --
 drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |  7 ++-
 3 files changed, 36 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpi/mpi2.h b/drivers/scsi/mpt3sas/mpi/mpi2.h
index b015c30..1e45268 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2.h
@@ -9,7 +9,7 @@
  * scatter/gather formats.
  * Creation Date:  June 21, 2006
  *
- * mpi2.h Version:  02.00.48
+ *  mpi2.h Version:  02.00.50
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -114,6 +114,8 @@
  * 09-02-16  02.00.46  Bumped MPI2_HEADER_VERSION_UNIT.
  * 11-23-16  02.00.47  Bumped MPI2_HEADER_VERSION_UNIT.
  * 02-03-17  02.00.48  Bumped MPI2_HEADER_VERSION_UNIT.
+ * 06-13-17  02.00.49  Bumped MPI2_HEADER_VERSION_UNIT.
+ * 09-29-17  02.00.50  Bumped MPI2_HEADER_VERSION_UNIT.
  * --
  */
 
@@ -152,8 +154,9 @@
MPI26_VERSION_MINOR)
 #define MPI2_VERSION_02_06 (0x0206)
 
-/*Unit and Dev versioning for this MPI header set */
-#define MPI2_HEADER_VERSION_UNIT(0x30)
+
+/* Unit and Dev versioning for this MPI header set */
+#define MPI2_HEADER_VERSION_UNIT(0x32)
 #define MPI2_HEADER_VERSION_DEV (0x00)
 #define MPI2_HEADER_VERSION_UNIT_MASK   (0xFF00)
 #define MPI2_HEADER_VERSION_UNIT_SHIFT  (8)
diff --git a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h 
b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
index 0ad88de..5122920 100644
--- a/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
+++ b/drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h
@@ -7,7 +7,7 @@
  * Title:  MPI Configuration messages and pages
  * Creation Date:  November 10, 2006
  *
- *   mpi2_cnfg.h Version:  02.00.40
+ *mpi2_cnfg.h Version:  02.00.42
  *
  * NOTE: Names (typedefs, defines, etc.) beginning with an MPI25 or Mpi25
  *   prefix are for use only on MPI v2.5 products, and must not be used
@@ -219,6 +219,18 @@
  * Added ChassisSlot field to SAS Enclosure Page 0.
  * Added ChassisSlot Valid bit (bit 5) to the Flags field
  * in SAS Enclosure Page 0.
+ * 06-13-17  02.00.41  Added MPI26_MFGPAGE_DEVID_SAS3816 and
+ * MPI26_MFGPAGE_DEVID_SAS3916 defines.
+ * Removed MPI26_MFGPAGE_DEVID_SAS4008 define.
+ * Added MPI26_PCIEIOUNIT1_LINKFLAGS_SRNS_EN define.
+ * Renamed PI26_PCIEIOUNIT1_LINKFLAGS_EN_SRIS to
+ * PI26_PCIEIOUNIT1_LINKFLAGS_SRIS_EN.
+ * Renamed MPI26_PCIEIOUNIT1_LINKFLAGS_DIS_SRIS to
+ * MPI26_PCIEIOUNIT1_LINKFLAGS_DIS_SEPARATE_REFCLK.
+ * 09-29-17  02.00.42  Added ControllerResetTO field to PCIe Device Page 2.
+ * Added NOIOB field to PCIe Device Page 2.
+ * Added MPI26_PCIEDEV2_CAP_DATA_BLK_ALIGN_AND_GRAN to
+ * the Capabilities field of PCIe Device Page 2.
  * --
  */
 
@@ -556,7 +568,8 @@ typedef struct _MPI2_CONFIG_REPLY {
 #define MPI26_MFGPAGE_DEVID_SAS3616 (0x00D1)
 #define MPI26_MFGPAGE_DEVID_SAS3708 (0x00D2)
 
-#define MPI26_MFGPAGE_DEVID_SAS4008 (0x00A1)
+#define MPI26_MFGPAGE_DEVID_SAS3816 (0x00A1)
+#define MPI26_MFGPAGE_DEVID_SAS3916 (0x00A0)
 
 
 /*Manufacturing Page 0 */
@@ -3864,20 +3877,25 @@ typedef struct _MPI26_CONFIG_PAGE_PCIEDEV_0 {
 typedef struct _MPI26_CONFIG_PAGE_PCIEDEV_2 {
MPI2_CONFIG_EXTENDED_PAGE_HEADERHeader; /*0x00 */
U16 DevHandle;  /*0x08 */
-   U16 Reserved1;  /*0x0A */
-   U32 MaximumDataTransferSize;/*0x0C */
+   U8  ControllerResetTO;  /* 0x0A */
+   U8  Reserved1;  /* 0x0B */
+   U32 MaximumDataTransferSize;/*0x0C */
U32 Capabilities;   /*0x10 */
-   U32 Reserved2;  /*0x14 */
+   U16 NOIOB;  /* 0x14 */
+   U16 Reserved2;  /* 0x16 */
 } MPI26_CONFIG_PAGE_PCIEDEV_2, *PTR_MPI26_CONFIG_PAGE_PCIEDEV_2,
Mpi26PCIeDevicePage2_t, *pMpi26PCIeDevicePage2_t;
 
-#define MPI26_PCIEDEVICE2_PAGEVERSION   (0x00)
+#define MPI26_PCIEDEVICE2_PAGEVERSION   (0x01)
 
 /*defines for PCIe Device Page 2 Capabilities field */
+#define MPI26_PCIEDEV2_CAP_DATA_BLK_ALIGN_AND_GRAN (0x0008)
 #define 

[PATCH v2 08/14] mpt3sas: Allow processing of events during driver unload.

2018-04-09 Thread Chaitra P B
Events were not processed during driver unload, hence unloading of driver
doesn't complete when drives are disconnected while unloading of driver.
So don't block events in ISR path, i,e., remove the flag ioc->remove_host
so that events are getting processed during driver unload.
Thus allowing driver unload to complete by processing drive removal events
during driver unload.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 796bf33..33587a8 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -3677,11 +3677,7 @@ _scsih_tm_tr_complete(struct MPT3SAS_ADAPTER *ioc, u16 
smid, u8 msix_index,
u32 ioc_state;
struct _sc_list *delayed_sc;
 
-   if (ioc->remove_host) {
-   dewtprintk(ioc, pr_info(MPT3SAS_FMT
-   "%s: host has been removed\n", __func__, ioc->name));
-   return 1;
-   } else if (ioc->pci_error_recovery) {
+   if (ioc->pci_error_recovery) {
dewtprintk(ioc, pr_info(MPT3SAS_FMT
"%s: host in pci error recovery\n", __func__,
ioc->name));
@@ -3803,8 +3799,7 @@ _scsih_tm_tr_volume_send(struct MPT3SAS_ADAPTER *ioc, u16 
handle)
u16 smid;
struct _tr_list *delayed_tr;
 
-   if (ioc->shost_recovery || ioc->remove_host ||
-   ioc->pci_error_recovery) {
+   if (ioc->pci_error_recovery) {
dewtprintk(ioc, pr_info(MPT3SAS_FMT
"%s: host reset in progress!\n",
__func__, ioc->name));
@@ -3857,8 +3852,7 @@ _scsih_tm_volume_tr_complete(struct MPT3SAS_ADAPTER *ioc, 
u16 smid,
Mpi2SCSITaskManagementReply_t *mpi_reply =
mpt3sas_base_get_reply_virt_addr(ioc, reply);
 
-   if (ioc->shost_recovery || ioc->remove_host ||
-   ioc->pci_error_recovery) {
+   if (ioc->shost_recovery || ioc->pci_error_recovery) {
dewtprintk(ioc, pr_info(MPT3SAS_FMT
"%s: host reset in progress!\n",
__func__, ioc->name));
@@ -9468,8 +9462,8 @@ mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER *ioc, 
u8 msix_index,
u16 sz;
Mpi26EventDataActiveCableExcept_t *ActiveCableEventData;
 
-   /* events turned off due to host reset or driver unloading */
-   if (ioc->remove_host || ioc->pci_error_recovery)
+   /* events turned off due to host reset */
+   if (ioc->pci_error_recovery)
return 1;
 
mpi_reply = mpt3sas_base_get_reply_virt_addr(ioc, reply);
-- 
1.8.3.1



[PATCH v2 02/14] mpt3sas: Pre-allocate RDPQ Array at driver boot time.

2018-04-09 Thread Chaitra P B
Instead of allocating RDPQ array (This stores the address's of each RDPQ
pools) at run time, now it will be allocated once during driver load time
and same will be reused during host reset operation also (instead of
allocating & freeing this buffer on the fly during every host reset
operation) and then freed during driver unload.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 57 +++--
 drivers/scsi/mpt3sas/mpt3sas_base.h |  3 ++
 2 files changed, 38 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 4767690..a79c6df 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4159,7 +4159,14 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
} while (ioc->rdpq_array_enable &&
   (++i < ioc->reply_queue_count));
-
+   if (ioc->reply_post_free_array &&
+   ioc->rdpq_array_enable) {
+   dma_pool_free(ioc->reply_post_free_array_dma_pool,
+   ioc->reply_post_free_array,
+   ioc->reply_post_free_array_dma);
+   ioc->reply_post_free_array = NULL;
+   }
+   dma_pool_destroy(ioc->reply_post_free_array_dma_pool);
dma_pool_destroy(ioc->reply_post_free_dma_pool);
kfree(ioc->reply_post);
}
@@ -4209,7 +4216,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
struct mpt3sas_facts *facts;
u16 max_sge_elements;
u16 chains_needed_per_io;
-   u32 sz, total_sz, reply_post_free_sz;
+   u32 sz, total_sz, reply_post_free_sz, reply_post_free_array_sz;
u32 retry_sz;
u16 max_request_credit, nvme_blocks_needed;
unsigned short sg_tablesize;
@@ -4681,6 +4688,28 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name, (unsigned long long)ioc->reply_free_dma));
total_sz += sz;
 
+   if (ioc->rdpq_array_enable) {
+   reply_post_free_array_sz = ioc->reply_queue_count *
+   sizeof(Mpi2IOCInitRDPQArrayEntry);
+   ioc->reply_post_free_array_dma_pool =
+   dma_pool_create("reply_post_free_array pool",
+   >pdev->dev, reply_post_free_array_sz, 16, 0);
+   if (!ioc->reply_post_free_array_dma_pool) {
+   dinitprintk(ioc,
+   pr_info(MPT3SAS_FMT "reply_post_free_array pool: "
+   "dma_pool_create failed\n", ioc->name));
+   goto out;
+   }
+   ioc->reply_post_free_array =
+   dma_pool_alloc(ioc->reply_post_free_array_dma_pool,
+   GFP_KERNEL, >reply_post_free_array_dma);
+   if (!ioc->reply_post_free_array) {
+   dinitprintk(ioc,
+   pr_info(MPT3SAS_FMT "reply_post_free_array pool: "
+   "dma_pool_alloc failed\n", ioc->name));
+   goto out;
+   }
+   }
ioc->config_page_sz = 512;
ioc->config_page = pci_alloc_consistent(ioc->pdev,
ioc->config_page_sz, >config_page_dma);
@@ -5487,8 +5516,6 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc)
ktime_t current_time;
u16 ioc_status;
u32 reply_post_free_array_sz = 0;
-   Mpi2IOCInitRDPQArrayEntry *reply_post_free_array = NULL;
-   dma_addr_t reply_post_free_array_dma;
 
dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
__func__));
@@ -5522,23 +5549,14 @@ _base_send_ioc_init(struct MPT3SAS_ADAPTER *ioc)
if (ioc->rdpq_array_enable) {
reply_post_free_array_sz = ioc->reply_queue_count *
sizeof(Mpi2IOCInitRDPQArrayEntry);
-   reply_post_free_array = pci_alloc_consistent(ioc->pdev,
-   reply_post_free_array_sz, _post_free_array_dma);
-   if (!reply_post_free_array) {
-   pr_err(MPT3SAS_FMT
-   "reply_post_free_array: pci_alloc_consistent failed\n",
-   ioc->name);
-   r = -ENOMEM;
-   goto out;
-   }
-   memset(reply_post_free_array, 0, reply_post_free_array_sz);
+   memset(ioc->reply_post_free_array, 0, reply_post_free_array_sz);
for (i = 0; i < ioc->reply_queue_count; i++)
-   reply_post_free_array[i].RDPQBaseAddress =
+   ioc->reply_post_free_array[i].RDPQBaseAddress =
cpu_to_le64(

[PATCH v2 00/14] mpt3sas: Enhancements and Defect fixes.

2018-04-09 Thread Chaitra P B
Chaitra P B (14):
  mpt3sas: Bug fix for big endian systems.
  mpt3sas: Pre-allocate RDPQ Array at driver boot time.
  mpt3sas: Lockless access for chain buffers.
  mpt3sas: Optimize I/O memory consumption in driver.
  mpt3sas: Enhanced handling of Sense Buffer.
  mpt3sas: Added support for SAS Device Discovery Error Event.
  mpt3sas: Increase event log buffer to support 24 port HBA's.
  mpt3sas: Allow processing of events during driver unload.
  mpt3sas: Cache enclosure pages during enclosure add.
  mpt3sas: Report Firmware Package Version from HBA Driver.
  mpt3sas: Update MPI Headers
  mpt3sas: For NVME device, issue a protocol level reset instead of
hot reset and use TM timeout value exposed in PCIe Device Page 2.
  mpt3sas: fix possible memory leak.
  mpt3sas: Update driver version "25.100.00.00"

 drivers/scsi/mpt3sas/mpi/mpi2.h  |   9 +-
 drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h |  30 +-
 drivers/scsi/mpt3sas/mpi/mpi2_init.h |   2 +-
 drivers/scsi/mpt3sas/mpi/mpi2_ioc.h  |   7 +-
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 477 +++---
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  62 +++-
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   |  33 ++-
 drivers/scsi/mpt3sas/mpt3sas_ctl.h   |   2 +-
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 491 +--
 drivers/scsi/mpt3sas/mpt3sas_warpdrive.c |   3 +-
 10 files changed, 818 insertions(+), 298 deletions(-)

-- 
1.8.3.1



[PATCH v2 14/14] mpt3sas: Update driver version "25.100.00.00"

2018-04-09 Thread Chaitra P B
Update driver version to match OOB/internal driver version.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 6a9657e..693b04b 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -74,8 +74,8 @@
 #define MPT3SAS_DRIVER_NAME"mpt3sas"
 #define MPT3SAS_AUTHOR "Avago Technologies "
 #define MPT3SAS_DESCRIPTION"LSI MPT Fusion SAS 3.0 Device Driver"
-#define MPT3SAS_DRIVER_VERSION "17.100.00.00"
-#define MPT3SAS_MAJOR_VERSION  17
+#define MPT3SAS_DRIVER_VERSION "25.100.00.00"
+#define MPT3SAS_MAJOR_VERSION  25
 #define MPT3SAS_MINOR_VERSION  100
 #define MPT3SAS_BUILD_VERSION  0
 #define MPT3SAS_RELEASE_VERSION00
-- 
1.8.3.1



[PATCH v2 03/14] mpt3sas: Lockless access for chain buffers.

2018-04-09 Thread Chaitra P B
Introduces Chain lookup table/tracker and implements accessing chain buffer
using smid.
Removed link list based access of chain buffer which requires lock and
allocated as many chains needed.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 111 +++-
 drivers/scsi/mpt3sas/mpt3sas_base.h |   8 ++-
 2 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index a79c6df..1e8e399 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -297,12 +297,15 @@ static void *
 _base_get_chain_buffer_dma_to_chain_buffer(struct MPT3SAS_ADAPTER *ioc,
dma_addr_t chain_buffer_dma)
 {
-   u16 index;
-
-   for (index = 0; index < ioc->chain_depth; index++) {
-   if (ioc->chain_lookup[index].chain_buffer_dma ==
-   chain_buffer_dma)
-   return ioc->chain_lookup[index].chain_buffer;
+   u16 index, j;
+   struct chain_tracker *ct;
+
+   for (index = 0; index < ioc->scsiio_depth; index++) {
+   for (j = 0; j < ioc->chains_needed_per_io; j++) {
+   ct = >chain_lookup[index].chains_per_smid[j];
+   if (ct && ct->chain_buffer_dma == chain_buffer_dma)
+   return ct->chain_buffer;
+   }
}
pr_info(MPT3SAS_FMT
"Provided chain_buffer_dma address is not in the lookup list\n",
@@ -1678,7 +1681,8 @@ _base_add_sg_single_64(void *paddr, u32 flags_length, 
dma_addr_t dma_addr)
  * @ioc: per adapter object
  * @scmd: SCSI commands of the IO request
  *
- * Returns chain tracker(from ioc->free_chain_list)
+ * Returns chain tracker from chain_lookup table using key as
+ * smid and smid's chain_offset.
  */
 static struct chain_tracker *
 _base_get_chain_buffer_tracker(struct MPT3SAS_ADAPTER *ioc,
@@ -1686,20 +1690,15 @@ _base_get_chain_buffer_tracker(struct MPT3SAS_ADAPTER 
*ioc,
 {
struct chain_tracker *chain_req;
struct scsiio_tracker *st = scsi_cmd_priv(scmd);
-   unsigned long flags;
+   u16 smid = st->smid;
+   u8 chain_offset =
+  atomic_read(>chain_lookup[smid - 1].chain_offset);
 
-   spin_lock_irqsave(>scsi_lookup_lock, flags);
-   if (list_empty(>free_chain_list)) {
-   spin_unlock_irqrestore(>scsi_lookup_lock, flags);
-   dfailprintk(ioc, pr_warn(MPT3SAS_FMT
-   "chain buffers not available\n", ioc->name));
+   if (chain_offset == ioc->chains_needed_per_io)
return NULL;
-   }
-   chain_req = list_entry(ioc->free_chain_list.next,
-   struct chain_tracker, tracker_list);
-   list_del_init(_req->tracker_list);
-   list_add_tail(_req->tracker_list, >chain_list);
-   spin_unlock_irqrestore(>scsi_lookup_lock, flags);
+
+   chain_req = >chain_lookup[smid - 1].chains_per_smid[chain_offset];
+   atomic_inc(>chain_lookup[smid - 1].chain_offset);
return chain_req;
 }
 
@@ -3278,13 +3277,7 @@ void mpt3sas_base_clear_st(struct MPT3SAS_ADAPTER *ioc,
return;
st->cb_idx = 0xFF;
st->direct_io = 0;
-   if (!list_empty(>chain_list)) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>scsi_lookup_lock, flags);
-   list_splice_init(>chain_list, >free_chain_list);
-   spin_unlock_irqrestore(>scsi_lookup_lock, flags);
-   }
+   atomic_set(>chain_lookup[st->smid - 1].chain_offset, 0);
 }
 
 /**
@@ -4102,6 +4095,8 @@ static void
 _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 {
int i = 0;
+   int j = 0;
+   struct chain_tracker *ct;
struct reply_post_struct *rps;
 
dexitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
@@ -4192,14 +4187,18 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
kfree(ioc->hpr_lookup);
kfree(ioc->internal_lookup);
if (ioc->chain_lookup) {
-   for (i = 0; i < ioc->chain_depth; i++) {
-   if (ioc->chain_lookup[i].chain_buffer)
-   dma_pool_free(ioc->chain_dma_pool,
-   ioc->chain_lookup[i].chain_buffer,
-   ioc->chain_lookup[i].chain_buffer_dma);
+   for (i = 0; i < ioc->scsiio_depth; i++) {
+   for (j = 0; j < ioc->chains_needed_per_io; j++) {
+   ct = >chain_lookup[i].chains_per_smid[j];
+   if (ct && ct->chain_buffer)
+   dma_pool_free(ioc->chain_dma_pool,
+   ct->chain_buffer,
+   ct->chain_buffer_dma);

[PATCH v2 06/14] mpt3sas: Added support for SAS Device Discovery Error Event.

2018-04-09 Thread Chaitra P B
The SAS Device Discovery Error Event is sent to the host when
discovery for a particular device is failed during discovery,
even after maximum retries by the IOC.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  |  4 
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 42 
 2 files changed, 46 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index bd1beaf..f9bacd2 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -1029,6 +1029,9 @@ _base_display_event_data(struct MPT3SAS_ADAPTER *ioc,
case MPI2_EVENT_ACTIVE_CABLE_EXCEPTION:
desc = "Cable Event";
break;
+   case MPI2_EVENT_SAS_DEVICE_DISCOVERY_ERROR:
+   desc = "SAS Device Discovery Error";
+   break;
case MPI2_EVENT_PCIE_DEVICE_STATUS_CHANGE:
desc = "PCIE Device Status Change";
break;
@@ -6596,6 +6599,7 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
_base_unmask_events(ioc, MPI2_EVENT_LOG_ENTRY_ADDED);
_base_unmask_events(ioc, MPI2_EVENT_TEMP_THRESHOLD);
_base_unmask_events(ioc, MPI2_EVENT_ACTIVE_CABLE_EXCEPTION);
+   _base_unmask_events(ioc, MPI2_EVENT_SAS_DEVICE_DISCOVERY_ERROR);
if (ioc->hba_mpi_version_belonged == MPI26_VERSION) {
if (ioc->is_gen35_ioc) {
_base_unmask_events(ioc,
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index c9cce65..796bf33 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -7524,6 +7524,44 @@ _scsih_sas_discovery_event(struct MPT3SAS_ADAPTER *ioc,
 }
 
 /**
+ * _scsih_sas_device_discovery_error_event - display SAS device discovery error
+ * events
+ * @ioc: per adapter object
+ * @fw_event: The fw_event_work object
+ * Context: user.
+ *
+ * Return nothing.
+ */
+static void
+_scsih_sas_device_discovery_error_event(struct MPT3SAS_ADAPTER *ioc,
+   struct fw_event_work *fw_event)
+{
+   Mpi25EventDataSasDeviceDiscoveryError_t *event_data =
+   (Mpi25EventDataSasDeviceDiscoveryError_t *)fw_event->event_data;
+
+   switch (event_data->ReasonCode) {
+   case MPI25_EVENT_SAS_DISC_ERR_SMP_FAILED:
+   pr_warn(MPT3SAS_FMT "SMP command sent to the expander"
+   "(handle:0x%04x, sas_address:0x%016llx,"
+   "physical_port:0x%02x) has failed",
+   ioc->name, le16_to_cpu(event_data->DevHandle),
+   (unsigned long long)le64_to_cpu(event_data->SASAddress),
+   event_data->PhysicalPort);
+   break;
+   case MPI25_EVENT_SAS_DISC_ERR_SMP_TIMEOUT:
+   pr_warn(MPT3SAS_FMT "SMP command sent to the expander"
+   "(handle:0x%04x, sas_address:0x%016llx,"
+   "physical_port:0x%02x) has timed out",
+   ioc->name, le16_to_cpu(event_data->DevHandle),
+   (unsigned long long)le64_to_cpu(event_data->SASAddress),
+   event_data->PhysicalPort);
+   break;
+   default:
+   break;
+   }
+}
+
+/**
  * _scsih_pcie_enumeration_event - handle enumeration events
  * @ioc: per adapter object
  * @fw_event: The fw_event_work object
@@ -9350,6 +9388,9 @@ _mpt3sas_fw_work(struct MPT3SAS_ADAPTER *ioc, struct 
fw_event_work *fw_event)
case MPI2_EVENT_SAS_DISCOVERY:
_scsih_sas_discovery_event(ioc, fw_event);
break;
+   case MPI2_EVENT_SAS_DEVICE_DISCOVERY_ERROR:
+   _scsih_sas_device_discovery_error_event(ioc, fw_event);
+   break;
case MPI2_EVENT_SAS_BROADCAST_PRIMITIVE:
_scsih_sas_broadcast_primitive_event(ioc, fw_event);
break;
@@ -9534,6 +9575,7 @@ mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER *ioc, 
u8 msix_index,
case MPI2_EVENT_SAS_DEVICE_STATUS_CHANGE:
case MPI2_EVENT_IR_OPERATION_STATUS:
case MPI2_EVENT_SAS_DISCOVERY:
+   case MPI2_EVENT_SAS_DEVICE_DISCOVERY_ERROR:
case MPI2_EVENT_SAS_ENCL_DEVICE_STATUS_CHANGE:
case MPI2_EVENT_IR_PHYSICAL_DISK:
case MPI2_EVENT_PCIE_ENUMERATION:
-- 
1.8.3.1



[PATCH v2 10/14] mpt3sas: Report Firmware Package Version from HBA Driver.

2018-04-09 Thread Chaitra P B
Added function _base_display_fwpkg_version, which sends FWUpload
request to pull FW package version from FW Image Header.
Now driver prints FW package version in addition to FW
version if the PackageVersion is valid.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 109 +++-
 drivers/scsi/mpt3sas/mpt3sas_base.h |   1 +
 2 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index fccf5d1..7f438be 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -3825,6 +3825,105 @@ _base_display_OEMs_branding(struct MPT3SAS_ADAPTER *ioc)
 }
 
 /**
+ * _base_display_fwpkg_version - sends FWUpload request to pull FWPkg
+ * version from FW Image Header.
+ * @ioc: per adapter object
+ *
+ * Returns 0 for success, non-zero for failure.
+ */
+   static int
+_base_display_fwpkg_version(struct MPT3SAS_ADAPTER *ioc)
+{
+   Mpi2FWImageHeader_t *FWImgHdr;
+   Mpi25FWUploadRequest_t *mpi_request;
+   Mpi2FWUploadReply_t mpi_reply;
+   int r = 0;
+   void *fwpkg_data = NULL;
+   dma_addr_t fwpkg_data_dma;
+   u16 smid, ioc_status;
+   size_t data_length;
+
+   dinitprintk(ioc, pr_info(MPT3SAS_FMT "%s\n", ioc->name,
+   __func__));
+
+   if (ioc->base_cmds.status & MPT3_CMD_PENDING) {
+   pr_err(MPT3SAS_FMT "%s: internal command already in use\n",
+   ioc->name, __func__);
+   return -EAGAIN;
+   }
+
+   data_length = sizeof(Mpi2FWImageHeader_t);
+   fwpkg_data = pci_alloc_consistent(ioc->pdev, data_length,
+   _data_dma);
+   if (!fwpkg_data) {
+   pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
+   ioc->name, __FILE__, __LINE__, __func__);
+   return -ENOMEM;
+   }
+
+   smid = mpt3sas_base_get_smid(ioc, ioc->base_cb_idx);
+   if (!smid) {
+   pr_err(MPT3SAS_FMT "%s: failed obtaining a smid\n",
+   ioc->name, __func__);
+   r = -EAGAIN;
+   goto out;
+   }
+
+   ioc->base_cmds.status = MPT3_CMD_PENDING;
+   mpi_request = mpt3sas_base_get_msg_frame(ioc, smid);
+   ioc->base_cmds.smid = smid;
+   memset(mpi_request, 0, sizeof(Mpi25FWUploadRequest_t));
+   mpi_request->Function = MPI2_FUNCTION_FW_UPLOAD;
+   mpi_request->ImageType = MPI2_FW_UPLOAD_ITYPE_FW_FLASH;
+   mpi_request->ImageSize = cpu_to_le32(data_length);
+   ioc->build_sg(ioc, _request->SGL, 0, 0, fwpkg_data_dma,
+   data_length);
+   init_completion(>base_cmds.done);
+   mpt3sas_base_put_smid_default(ioc, smid);
+   /* Wait for 15 seconds */
+   wait_for_completion_timeout(>base_cmds.done,
+   FW_IMG_HDR_READ_TIMEOUT*HZ);
+   pr_info(MPT3SAS_FMT "%s: complete\n",
+   ioc->name, __func__);
+   if (!(ioc->base_cmds.status & MPT3_CMD_COMPLETE)) {
+   pr_err(MPT3SAS_FMT "%s: timeout\n",
+   ioc->name, __func__);
+   _debug_dump_mf(mpi_request,
+   sizeof(Mpi25FWUploadRequest_t)/4);
+   r = -ETIME;
+   } else {
+   memset(_reply, 0, sizeof(Mpi2FWUploadReply_t));
+   if (ioc->base_cmds.status & MPT3_CMD_REPLY_VALID) {
+   memcpy(_reply, ioc->base_cmds.reply,
+   sizeof(Mpi2FWUploadReply_t));
+   ioc_status = le16_to_cpu(mpi_reply.IOCStatus) &
+   MPI2_IOCSTATUS_MASK;
+   if (ioc_status == MPI2_IOCSTATUS_SUCCESS) {
+   FWImgHdr = (Mpi2FWImageHeader_t *)fwpkg_data;
+   if (FWImgHdr->PackageVersion.Word) {
+   pr_info(MPT3SAS_FMT "FW Package Version"
+   "(%02d.%02d.%02d.%02d)\n",
+   ioc->name,
+   FWImgHdr->PackageVersion.Struct.Major,
+   FWImgHdr->PackageVersion.Struct.Minor,
+   FWImgHdr->PackageVersion.Struct.Unit,
+   FWImgHdr->PackageVersion.Struct.Dev);
+   }
+   } else {
+   _debug_dump_mf(_reply,
+   sizeof(Mpi2FWUploadReply_t)/4);
+   }
+   }
+   }
+   ioc->base_cmds.status = MPT3_CMD_NOT_USED;
+out:
+   if (fwpkg_data)
+   

[PATCH v2 05/14] mpt3sas: Enhanced handling of Sense Buffer.

2018-04-09 Thread Chaitra P B
Enhanced DMA allocation for Sense Buffer, if the allocation does not fit
within same 4GB.Introduced is_MSB_are_same function to check if allocted
buffer within 4GB range or not.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 56 +
 1 file changed, 56 insertions(+)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 701e1e7..bd1beaf 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4205,6 +4205,31 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 }
 
 /**
+ * is_MSB_are_same - checks whether all reply queues in a set are
+ * having same upper 32bits in their base memory address.
+ * @reply_pool_start_address: Base address of a reply queue set
+ * @pool_sz: Size of single Reply Descriptor Post Queues pool size
+ *
+ * Returns 1 if reply queues in a set have a same upper 32bits
+ * in their base memory address,
+ * else 0
+ */
+
+static int
+is_MSB_are_same(long reply_pool_start_address, u32 pool_sz)
+{
+   long reply_pool_end_address;
+
+   reply_pool_end_address = reply_pool_start_address + pool_sz;
+
+   if (upper_32_bits(reply_pool_start_address) ==
+   upper_32_bits(reply_pool_end_address))
+   return 1;
+   else
+   return 0;
+}
+
+/**
  * _base_allocate_memory_pools - allocate start of day memory pools
  * @ioc: per adapter object
  *
@@ -4664,6 +4689,37 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
+   /* sense buffer requires to be in same 4 gb region.
+* Below function will check the same.
+* In case of failure, new pci pool will be created with updated
+* alignment. Older allocation and pool will be destroyed.
+* Alignment will be used such a way that next allocation if
+* success, will always meet same 4gb region requirement.
+* Actual requirement is not alignment, but we need start and end of
+* DMA address must have same upper 32 bit address.
+*/
+   if (!is_MSB_are_same((long)ioc->sense, sz)) {
+   //Release Sense pool & Reallocate
+   dma_pool_free(ioc->sense_dma_pool, ioc->sense, ioc->sense_dma);
+   dma_pool_destroy(ioc->sense_dma_pool);
+   ioc->sense = NULL;
+
+   ioc->sense_dma_pool =
+   dma_pool_create("sense pool", >pdev->dev, sz,
+   roundup_pow_of_two(sz), 0);
+   if (!ioc->sense_dma_pool) {
+   pr_err(MPT3SAS_FMT "sense pool: pci_pool_create 
failed\n",
+   ioc->name);
+   goto out;
+   }
+   ioc->sense = dma_pool_alloc(ioc->sense_dma_pool, GFP_KERNEL,
+   >sense_dma);
+   if (!ioc->sense) {
+   pr_err(MPT3SAS_FMT "sense pool: pci_pool_alloc 
failed\n",
+   ioc->name);
+   goto out;
+   }
+   }
dinitprintk(ioc, pr_info(MPT3SAS_FMT
"sense pool(0x%p): depth(%d), element_size(%d), pool_size"
"(%d kB)\n", ioc->name, ioc->sense, ioc->scsiio_depth,
-- 
1.8.3.1



[PATCH v2 13/14] mpt3sas: fix possible memory leak.

2018-04-09 Thread Chaitra P B
In ioctl exit path driver refers ioc_list to free memory associated with
diag buffers and event_log pointer used to save events by driver.
If ctl_exit() func is called after unregistering driver, then ioc_list will
be empty and hence driver will not be able to free the allocated memory
which in turn causes memory leak.
So call ctl_exit() function before unregistering mpt3sas driver.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 8ba72a2..8fc2922 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -11276,10 +11276,10 @@ _mpt3sas_exit(void)
pr_info("mpt3sas version %s unloading\n",
MPT3SAS_DRIVER_VERSION);
 
-   pci_unregister_driver(_driver);
-
mpt3sas_ctl_exit(hbas_to_enumerate);
 
+   pci_unregister_driver(_driver);
+
scsih_exit();
 }
 
-- 
1.8.3.1



[PATCH v2 12/14] mpt3sas: For NVME device, issue a protocol level reset instead of hot reset and use TM timeout value exposed in PCIe Device Page 2.

2018-04-09 Thread Chaitra P B
1)Manufacturing Page 11 contains parameters to control
internal firmware behavior. Based on AddlFlags2 field
FW/Driver behaviour can be changed, (flag tm_custom_handling
is used for this)

a) For PCIe device, protocol level reset should be used if
flag tm_custom_handling is 0.
Since Abort Task Set, LUN reset and Target reset will result
in a protocol level reset. Drivers should issue only one type
of this reset, if that fails then it should escalate to a controller
reset (diag reset/OCR).
b) If the driver has control over the TM reset timeout value, then
driver should use the value exposed in PCIe Device Page 2 for pcie device
(field ControllerResetTO).

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  | 13 ++
 drivers/scsi/mpt3sas/mpt3sas_base.h  | 26 ++--
 drivers/scsi/mpt3sas/mpt3sas_ctl.c   | 22 +--
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 76 ++--
 4 files changed, 116 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 7f438be..eaeace0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4139,6 +4139,7 @@ _base_static_config_pages(struct MPT3SAS_ADAPTER *ioc)
Mpi2ConfigReply_t mpi_reply;
u32 iounit_pg1_flags;
 
+   ioc->nvme_abort_timeout = 30;
mpt3sas_config_get_manufacturing_pg0(ioc, _reply, >manu_pg0);
if (ioc->ir_firmware)
mpt3sas_config_get_manufacturing_pg10(ioc, _reply,
@@ -4157,6 +4158,18 @@ _base_static_config_pages(struct MPT3SAS_ADAPTER *ioc)
mpt3sas_config_set_manufacturing_pg11(ioc, _reply,
>manu_pg11);
}
+   if (ioc->manu_pg11.AddlFlags2 & NVME_TASK_MNGT_CUSTOM_MASK)
+   ioc->tm_custom_handling = 1;
+   else {
+   ioc->tm_custom_handling = 0;
+   if (ioc->manu_pg11.NVMeAbortTO < NVME_TASK_ABORT_MIN_TIMEOUT)
+   ioc->nvme_abort_timeout = NVME_TASK_ABORT_MIN_TIMEOUT;
+   else if (ioc->manu_pg11.NVMeAbortTO >
+   NVME_TASK_ABORT_MAX_TIMEOUT)
+   ioc->nvme_abort_timeout = NVME_TASK_ABORT_MAX_TIMEOUT;
+   else
+   ioc->nvme_abort_timeout = ioc->manu_pg11.NVMeAbortTO;
+   }
 
mpt3sas_config_get_bios_pg2(ioc, _reply, >bios_pg2);
mpt3sas_config_get_bios_pg3(ioc, _reply, >bios_pg3);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 20fe90d..6a9657e 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -146,8 +146,12 @@
 #defineNVME_CMD_PRP1_OFFSET24  /* PRP1 offset in NVMe 
cmd */
 #defineNVME_CMD_PRP2_OFFSET32  /* PRP2 offset in NVMe 
cmd */
 #defineNVME_ERROR_RESPONSE_SIZE16  /* Max NVME Error 
Response */
+#define NVME_TASK_ABORT_MIN_TIMEOUT6
+#define NVME_TASK_ABORT_MAX_TIMEOUT60
+#define NVME_TASK_MNGT_CUSTOM_MASK (0x0010)
 #defineNVME_PRP_PAGE_SIZE  4096/* Page size */
 
+
 /*
  * reset phases
  */
@@ -363,7 +367,15 @@ struct Mpi2ManufacturingPage11_t {
u8  EEDPTagMode;/* 09h */
u8  Reserved3;  /* 0Ah */
u8  Reserved4;  /* 0Bh */
-   __le32  Reserved5[23];  /* 0Ch-60h*/
+   __le32  Reserved5[8];   /* 0Ch-2Ch */
+   u16 AddlFlags2; /* 2Ch */
+   u8  AddlFlags3; /* 2Eh */
+   u8  Reserved6;  /* 2Fh */
+   __le32  Reserved7[7];   /* 30h - 4Bh */
+   u8  NVMeAbortTO;/* 4Ch */
+   u8  Reserved8;  /* 4Dh */
+   u16 Reserved9;  /* 4Eh */
+   __le32  Reserved10[4];  /* 50h - 60h */
 };
 
 /**
@@ -573,6 +585,7 @@ struct _pcie_device {
u8  enclosure_level;
u8  connector_name[4];
u8  *serial_number;
+   u8  reset_timeout;
struct kref refcount;
 };
 /**
@@ -1211,6 +1224,10 @@ struct MPT3SAS_ADAPTER {
void*event_log;
u32 event_masks[MPI2_EVENT_NOTIFY_EVENTMASK_WORDS];
 
+   u8  tm_custom_handling;
+   u8  nvme_abort_timeout;
+
+
/* static config pages */
struct mpt3sas_facts facts;
struct mpt3sas_port_facts *pfacts;
@@ -1470,10 +1487,11 @@ u8 mpt3sas_scsih_event_callback(struct MPT3SAS_ADAPTER 
*ioc, u8 msix_index,
u32 reply);
 void mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER *ioc, int reset_phase);
 
-int mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 

[PATCH v2 04/14] mpt3sas: Optimize I/O memory consumption in driver.

2018-04-09 Thread Chaitra P B
For every IO, memory of PAGE size is allocated for handling NVMe native
PRPS. And in addition to that for every IO (chains need per IO * chain
buffer size, e.g. 38 * 128byte) amount of memory is allocated for chain
buffers.

However, at any point of time; the IO request can be for NVMe target device
(where PRP's page is used for framing PRP's) or can be for SCSI target
device (where chain buffers are used for framing chain SGE's). This patch
modifies the driver to reuse same pre-allocated PRP page buffers as a chain
buffer for IO's targeted for SCSI target devices. No need to allocate
separate buffers for chain SGE's buffers.

Suppose if the number of chain buffers need for IO doesn't fit in the PRP
Page size then driver maintain's separate buffers for those extra chain
buffers that exceeds the PRP page size. For example consider PRP page size
as 4K and chain buffer size as 128 bytes, then number of chain buffers that
can fit in PRP page is 4096/128 => 32. if the number of chain buffer need
per IO exceeds 32; for example consider number of chains need per IO is 36
then for remaining 4 chain buffer's driver allocates them individual.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 80 +++--
 1 file changed, 51 insertions(+), 29 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 1e8e399..701e1e7 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4188,7 +4188,8 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER *ioc)
kfree(ioc->internal_lookup);
if (ioc->chain_lookup) {
for (i = 0; i < ioc->scsiio_depth; i++) {
-   for (j = 0; j < ioc->chains_needed_per_io; j++) {
+   for (j = ioc->chains_per_prp_buffer;
+   j < ioc->chains_needed_per_io; j++) {
ct = >chain_lookup[i].chains_per_smid[j];
if (ct && ct->chain_buffer)
dma_pool_free(ioc->chain_dma_pool,
@@ -4506,7 +4507,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->chain_lookup = kzalloc(sz, GFP_KERNEL);
if (!ioc->chain_lookup) {
pr_err(MPT3SAS_FMT "chain_lookup: __get_free_pages "
-   "failed\n", ioc->name);
+   "failed\n", ioc->name);
goto out;
}
 
@@ -4520,33 +4521,6 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
}
}
 
-   ioc->chain_dma_pool = dma_pool_create("chain pool", >pdev->dev,
-   ioc->chain_segment_sz, 16, 0);
-   if (!ioc->chain_dma_pool) {
-   pr_err(MPT3SAS_FMT "chain_dma_pool: dma_pool_create failed\n",
-   ioc->name);
-   goto out;
-   }
-   for (i = 0; i < ioc->scsiio_depth; i++) {
-   for (j = 0; j < ioc->chains_needed_per_io; j++) {
-   ct = >chain_lookup[i].chains_per_smid[j];
-   ct->chain_buffer = dma_pool_alloc(
-   ioc->chain_dma_pool , GFP_KERNEL,
-   >chain_buffer_dma);
-   if (!ct->chain_buffer) {
-   pr_err(MPT3SAS_FMT "chain_lookup: "
-   " pci_pool_alloc failed\n", ioc->name);
-   goto out;
-   }
-   }
-   total_sz += ioc->chain_segment_sz;
-   }
-
-   dinitprintk(ioc, pr_info(MPT3SAS_FMT
-   "chain pool depth(%d), frame_size(%d), pool_size(%d kB)\n",
-   ioc->name, ioc->chain_depth, ioc->chain_segment_sz,
-   ((ioc->chain_depth *  ioc->chain_segment_sz))/1024));
-
/* initialize hi-priority queue smid's */
ioc->hpr_lookup = kcalloc(ioc->hi_priority_depth,
sizeof(struct request_tracker), GFP_KERNEL);
@@ -4587,6 +4561,7 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
 * be required for NVMe PRP's, only each set of NVMe blocks will be
 * contiguous, so a new set is allocated for each possible I/O.
 */
+   ioc->chains_per_prp_buffer = 0;
if (ioc->facts.ProtocolFlags & MPI2_IOCFACTS_PROTOCOL_NVME_DEVICES) {
nvme_blocks_needed =
(ioc->shost->sg_tablesize * NVME_PRP_SIZE) - 1;
@@ -4609,6 +4584,11 @@ _base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
ioc->name);
goto out;
}
+
+   ioc->chains_per_prp_buffer = sz/ioc->chain_segment_sz;
+   ioc->chains_per_prp_buffer = min(ioc->chains_per_prp_buffer,
+   ioc->chains_needed_per_io);
+

[PATCH v2 09/14] mpt3sas: Cache enclosure pages during enclosure add.

2018-04-09 Thread Chaitra P B
In function _scsih_add_device,
for each device connected to an enclosure, driver reads the
enclosure page(To get details like enclosure handle,
enclosure logical ID, enclosure level etc.)

With this patch, instead of reading enclosure page everytime,
driver maintains a list for enclosure device(During enclosure
add event, enclosure device is added to the list and removed
from the list on delete events) and uses the enclosure page
from the list.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c  |  22 +++
 drivers/scsi/mpt3sas/mpt3sas_base.h  |  14 ++
 drivers/scsi/mpt3sas/mpt3sas_scsih.c | 296 +++
 3 files changed, 236 insertions(+), 96 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index f9bacd2..fccf5d1 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -4087,6 +4087,27 @@ _base_static_config_pages(struct MPT3SAS_ADAPTER *ioc)
 }
 
 /**
+ * mpt3sas_free_enclosure_list - release memory
+ * @ioc: per adapter object
+ *
+ * Free memory allocated during encloure add.
+ *
+ * Return nothing.
+ */
+void
+mpt3sas_free_enclosure_list(struct MPT3SAS_ADAPTER *ioc)
+{
+   struct _enclosure_node *enclosure_dev, *enclosure_dev_next;
+
+   /* Free enclosure list */
+   list_for_each_entry_safe(enclosure_dev,
+   enclosure_dev_next, >enclosure_list, list) {
+   list_del(_dev->list);
+   kfree(enclosure_dev);
+   }
+}
+
+/**
  * _base_release_memory_pools - release memory
  * @ioc: per adapter object
  *
@@ -,6 +6687,7 @@ mpt3sas_base_detach(struct MPT3SAS_ADAPTER *ioc)
mpt3sas_base_stop_watchdog(ioc);
mpt3sas_base_free_resources(ioc);
_base_release_memory_pools(ioc);
+   mpt3sas_free_enclosure_list(ioc);
pci_set_drvdata(ioc->pdev, NULL);
kfree(ioc->cpu_msix_table);
if (ioc->is_warpdrive)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h 
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index a0fca8a..6f3329e 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -741,6 +741,17 @@ struct _sas_node {
struct list_head sas_port_list;
 };
 
+
+/**
+ * struct _enclosure_node - enclosure information
+ * @list: list of enclosures
+ * @pg0: enclosure pg0;
+ */
+struct _enclosure_node {
+   struct list_head list;
+   Mpi2SasEnclosurePage0_t pg0;
+};
+
 /**
  * enum reset_type - reset state
  * @FORCE_BIG_HAMMER: issue diagnostic reset
@@ -1013,6 +1024,7 @@ typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct 
MPT3SAS_ADAPTER *ioc);
  * @iounit_pg8: static iounit page 8
  * @sas_hba: sas host object
  * @sas_expander_list: expander object list
+ * @enclosure_list: enclosure object list
  * @sas_node_lock:
  * @sas_device_list: sas device object list
  * @sas_device_init_list: sas device object list (used only at init time)
@@ -1218,6 +1230,7 @@ struct MPT3SAS_ADAPTER {
/* sas hba, expander, and device list */
struct _sas_node sas_hba;
struct list_head sas_expander_list;
+   struct list_head enclosure_list;
spinlock_t  sas_node_lock;
struct list_head sas_device_list;
struct list_head sas_device_init_list;
@@ -1391,6 +1404,7 @@ int mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc);
 void mpt3sas_base_detach(struct MPT3SAS_ADAPTER *ioc);
 int mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc);
 void mpt3sas_base_free_resources(struct MPT3SAS_ADAPTER *ioc);
+void mpt3sas_free_enclosure_list(struct MPT3SAS_ADAPTER *ioc);
 int mpt3sas_base_hard_reset_handler(struct MPT3SAS_ADAPTER *ioc,
enum reset_type type);
 
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c 
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index 33587a8..bc8e7f0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -1362,6 +1362,30 @@ mpt3sas_scsih_expander_find_by_handle(struct 
MPT3SAS_ADAPTER *ioc, u16 handle)
 }
 
 /**
+ * mpt3sas_scsih_enclosure_find_by_handle - exclosure device search
+ * @ioc: per adapter object
+ * @handle: enclosure handle (assigned by firmware)
+ * Context: Calling function should acquire ioc->sas_device_lock
+ *
+ * This searches for enclosure device based on handle, then returns the
+ * enclosure object.
+ */
+static struct _enclosure_node *
+mpt3sas_scsih_enclosure_find_by_handle(struct MPT3SAS_ADAPTER *ioc, u16 handle)
+{
+   struct _enclosure_node *enclosure_dev, *r;
+
+   r = NULL;
+   list_for_each_entry(enclosure_dev, >enclosure_list, list) {
+   if (le16_to_cpu(enclosure_dev->pg0.EnclosureHandle) != handle)
+   continue;
+   r = enclosure_dev;
+   goto out;
+   }
+out:
+   return r;
+}
+/**
  * mpt3sas_scsih_expander_find_by_sas_address - expander device 

[PATCH v2 07/14] mpt3sas: Increase event log buffer to support 24 port HBA's.

2018-04-09 Thread Chaitra P B
For 24 port HBA's events generated by IOC are more in certain cases and
the current circular buffer may be overwritten.Hence increased the event
log buffer to accommodate more events.

Signed-off-by: Chaitra P B 
Signed-off-by: Suganath Prabu S 
---
 drivers/scsi/mpt3sas/mpt3sas_ctl.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.h 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
index a44046c..18b46fa 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.h
@@ -184,7 +184,7 @@ struct mpt3_ioctl_iocinfo {
 
 
 /* number of event log entries */
-#define MPT3SAS_CTL_EVENT_LOG_SIZE (50)
+#define MPT3SAS_CTL_EVENT_LOG_SIZE (200)
 
 /**
  * struct mpt3_ioctl_eventquery - query event count and type
-- 
1.8.3.1



Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-09 Thread Geert Uytterhoeven
Hi Christoph,

On Mon, Apr 9, 2018 at 9:50 AM, Christoph Hellwig  wrote:
> On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
>> --- /dev/null
>> +++ b/drivers/scsi/zorro_esp.c

>> + .driver_data = (unsigned long)_data,
>
> What most (or at least many) drivers do in PCI land is to just use
> an enum of types in the driver_Data field and use that as an index for
> for decisions later.  It seems like that might be the cleaner method
> here as well.

That may work fine for a small number of differences.
For more differences, the pointer to the feature struct is what most DT
drivers use (of_device_id.data is a const void *).

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


Re: usercopy whitelist woe in scsi_sense_cache

2018-04-09 Thread Christoph Hellwig
I really can't make sense of that report.  And I'm also curious why
you think 17cb960f29c2 should change anything for that code path.


Re: [PATCHv2] target: prefer dbroot of /etc/target over /var/target

2018-04-09 Thread Christoph Hellwig
This looks reasonable to me:

Reviewed-by: Christoph Hellwig 


Re: Multi-Actuator SAS HDD First Look

2018-04-09 Thread Christoph Hellwig
On Fri, Apr 06, 2018 at 01:09:08PM -0400, Douglas Gilbert wrote:
> So you found a document that outlines NVMe's architecture! Could you
> share the url (no marketing BS, please)?

You can always take a look at the actual spec:

http://nvmexpress.org/wp-content/uploads/NVM-Express-1_3a-20171024_ratified.pdf

But in summary: while in SCSI your Nexus for any command is with the
logic unit, in NVMe it is with the controller.   Many admin commands
operate on the whole controller.

> And a serious question ... How would you map NVMe's (in Linux)
> subsystem number, controller device minor number, CNTLID field
> (Identify ctl response) and namespace id onto the SCSI subsystem's
> h:c:t:l ?

I wouldn't because the scheme already doesn't make any sense for SCSI,
nevermind should we try to map NVMe into a scsi specific worldview.

> 
> Doug Gilbert
> 
---end quoted text---


Re: 答复: Re: 答复: Re: [PATCH v2] scsi: Introduce sdev_printk_ratelimited tothrottlefrequent printk

2018-04-09 Thread Petr Mladek
On Mon 2018-04-09 10:13:43, wen.yan...@zte.com.cn wrote:
> That's a good idea, but it only solves part of the problem.
>  loopping printks under spinlock, there's two path:
> one path is: 

> scsi_request_fn -->  loop ->  blk_peek_request-> scsi_prep_fn -> 
> scsi_prep_state_check -> sdev_printk

> another path is:

> scsi_request_fn -->  loop ->  sdev_printk

Is this message redundant? It seems to be printed in the same
situations as the messages in scsi_prep_state_check().

In fact, there seems to be a mismatch. scsi_request_fn() prints
about offline device also for sdev->sdev_state == SDEV_DEL.
While scsi_prep_state_check() prints about a dead device
in this case.

Would it make sense to remove the redundant dev_printk() from
scsi_request_fn()?


Then we could add a flag into struct scsi_device that
would remember if we already printed the error in
scsi_prep_state_check() for the given device. It could
be used to print the error only once.

The flag might be scsi_device_state value for which
we printed the error last time. We would need to reset
it scsi_prep_state_check() see another state.

It is a bit hairy but it really does not make much sense
to print the same error message thousand times.

Best Regards,
Petr

PS: Your mail was again strangely formatted. Please, send
mails in plain text format (no html).


RE: [PATCH v1 03/15] mpt3sas: Add sanity checks for scsi tracker before accessing it.

2018-04-09 Thread Chaitra Basappa
Bart,
 We will work on this patch and submit. As of now reposting all the patches
of this series except this patch.

Thanks,
 Chaitra


-Original Message-
From: Bart Van Assche [mailto:bart.vanass...@wdc.com]
Sent: Friday, April 6, 2018 8:59 PM
To: chaitra.basa...@broadcom.com; linux-scsi@vger.kernel.org
Cc: sathya.prak...@broadcom.com; sreekanth.re...@broadcom.com;
suganath-prabu.subram...@broadcom.com
Subject: Re: [PATCH v1 03/15] mpt3sas: Add sanity checks for scsi tracker
before accessing it.

On Thu, 2018-04-05 at 11:46 -0400, Chaitra P B wrote:
> Check scsi tracker 'st' for NULL and st->smid for zero (as driver uses
> smid starting from one) before accessing it.
> These checks are added as there are possibilities for getting valid
> scsi_cmd when driver calls scsi_host_find_tag() API when it loops
> using smid(i.e tag) from one to hba queue depth but still scsi tracker
> st for this corresponding scsi_cmd is not yet initialized.
>
> For example below are such scenario:
> Sometimes it is possible that scsi_cmd might have created at SML but
> it might not be issued to the driver (or driver might have returned
> the command with Host busy status) as the host reset operation / TMs
> is in progress.In such case where the scsi_cmd is not yet processed by
> driver then the scsi tracker 'st' of that scsi_cmd & the fields of
> this 'st' will be uninitialized.
> And hence this patch add checks for 'st' in IOCTL path for TMs issued
> from applications and also in host reset path where driver flushes all
> the outstanding commands as part of host reset operation.

What is needed is an explanation about which mechanism serializes the
execution of scsih_qcmd() and mpt3sas_base_hard_reset_handler(), at least if
such a mechanism exists. The above text does not mention anything about such
a synchronization mechanism.

>   scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
> - if (!scmd)
> + if (scmd == NULL || scmd->device == NULL ||
> + scmd->device->hostdata == NULL)

As Christoph explained before, scmd->device is never NULL. Additionally, the
scmd->device->hostdata check looks very suspicious. That check should
scmd->device->either
be left out or the race that causes a SCSI device to be removed concurrently
with this function should be fixed.

If you are unable to motivate why this patch is correct, please repost this
series without this patch.

Thanks,

Bart.


Re: [PATCH 11/14] lpfc: Fix NULL pointer reference when resetting adapter

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:23 -0700
James Smart  wrote:

> Points referencing local port structures didn't accommodate cases
> where the localport may not be registered yet.
> 
> Add NULL pointer checks to logic.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_nvme.c | 36
>  1 file changed, 20
> insertions(+), 16 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes



Re: [PATCH 12/14] lpfc: Fix create_association oops on unloading LPFC driver

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:24 -0700
James Smart  wrote:

> Driver unload isn't waiting for all outstanding nvme associations
> to terminate before clearing structures. In particular, it did not
> set dev_loss_tmo to 0 such that all associations are immediately
> terminated. Thus the transport would enter reconnect timeouts and
> reattempt reconnect to an nvme controller. The call makes a call
> into the driver to create hw queues for the controller which causes
> a NULL pointer reference.
> 
> Correct by changing the teardown process to change all dev_loss_tmo
> timeouts to 0 so that they are immediate. Now the teardown process
> initiates, the remote ports unregistered and delete callback made,
> and as the assocations are immediate upon remoteport unregister, the
> transport will not longer invoke the callbacks for a new controller.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_hbadisc.c | 20 
>  1 file changed, 20 insertions(+)
> 

Hmm. This seems to be a very circumspect way of deleting all
outstanding I/O...
Is there any guarantee that nvme_fc_set_remoteport_devloss() will
return only after all callbacks are invoked?

Cheers,

Hannes


Re: [PATCH 14/14] lpfc: update driver version to 12.0.0.2

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:26 -0700
James Smart  wrote:

> Update the driver version to 12.0.0.2
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_version.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/lpfc/lpfc_version.h
> b/drivers/scsi/lpfc/lpfc_version.h index e8b089abbfb3..0cd474bb0bdd
> 100644 --- a/drivers/scsi/lpfc/lpfc_version.h
> +++ b/drivers/scsi/lpfc/lpfc_version.h
> @@ -20,7 +20,7 @@
>   * included with this package. *
>   ***/
>  
> -#define LPFC_DRIVER_VERSION "12.0.0.1"
> +#define LPFC_DRIVER_VERSION "12.0.0.2"
>  #define LPFC_DRIVER_NAME "lpfc"
>  
>  /* Used for SLI 2/3 */

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes



Re: [PATCH 13/14] lpfc: Correct missing remoteport registration during link bounces

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:25 -0700
James Smart  wrote:

> Remote port disappearance/reappearances would cause a series of RSCN
> events to be delivered to the driver. During the resulting GID_FT
> handling, the driver clears the fc4 settings on the remote port, which
> makes it skip registration. As such, the nvme associations eventually
> fail and return io errors to the applications.
> 
> Correct by not clearng the nlp_fc4_types for all nodes in
> lpfc_issue_gidft. Instead, when the GID_FT response is handled, clear
> the nlp_fc4_types of FCP and NVME prior to evaluating the fc4_type
> returned by the GID_FT response.  This approach leaves "skipped"
> nodes with their nlp_fc4_types intacted.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_ct.c  | 5 +
>  drivers/scsi/lpfc/lpfc_hbadisc.c | 4 
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes



Re: [PATCH 10/14] lpfc: Fix nvme remoteport registration race conditions

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:22 -0700
James Smart  wrote:

> On tests adding and removing a remote port, calls to nvme_info would
> eventually show fewer target ports discovered than were present in
> the san. Additionally, the following error messages were seen:
>   6031 RemotePort Registration failed err: -116, DID x471301
> 
> There is a race condition that exists between the driver and the nvme
> transport on remote port unregister vs the confirmed deletion. It's
> possible that the driver may rediscover the remote port and reregister
> the remote port before a prior unregister delete callback was made
> (as it rebinded to the prior remoteport structure). However, the
> driver was coded to expect the callback before seeing the remote
> port again thus a new registration. The logic results in the driver
> having an invalid remoteport pointer set.
> 
> Correct by tracking when waiting for the delete callback. In cases
> where the ndlp remoteport pointer is updated, it is only cleared
> when the wait has not been superceded by a prior registration.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_nvme.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-09 Thread Christoph Hellwig
On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote:
> New combined SCSI driver for all ESP based Zorro SCSI boards for
> m68k Amiga.
> 
> Code largely based on board specific parts of the old drivers (blz1230.c,
> blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed
> after the 2.6 kernel series for lack of maintenance) with contributions
> by Tuomas Vainikka (TCQ bug tests and workaround) and Finn Thain (TCQ
> bugfix by use of PIO in extended message in transfer).
> 
> New Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI
> driver included in this patch.
> 
> Use DMA transfers wherever possible, with board-specific DMA set-up
> functions copied from the old driver code. Three byte reselection messages
> do appear to cause DMA timeouts. So wire up a PIO transfer routine for
> these instead. esp_reselect_with_tag explicitly sets esp->cmd_block_dma as
> target address for the message bytes but PIO requires a virtual address.
> Substiute kernel virtual address esp->cmd_block in PIO transfer call if
> DMA address is esp->cmd_block_dma and phase is message in.
> 
> PIO code taken from mac_esp.c where the reselection timeout issue was
> debugged and fixed first, with minor macro and function rename.
> 
> Signed-off-by: Michael Schmitz 
> Reviewed-by: Finn Thain 
> 
> ---
> 
> Changes since v1:
> 
> Fixed issues raised by Finn Thain in initial code review:
> 
> - use KBUILD_MODNAME for driver name string.
> - use pr_fmt() for pr_* format prefix.
> - clean up DMA error reporting: clear error flag before each DMA
>   operation, set error flag on PIO error. Don't test phase in dma_err hook.
> - change confusing comment about semantics of read flag, add comments
>   indicating DMA direction to DMA setup hooks.
> - drop spurious braces around switch clauses.
> - lift cfreq setting out of ID switch clauses.
> - fix indentation.
> - fix error codes on probe fail.
> - drop check for board ID when unmapping DMA regs in error handling:
>   the ioaddr > 0xff test already catches all cases where the DMA
>   registers were ioremapped.
> - dynamically alloc zorro_private_data.
> - fix use of driver_data field (don't mix host and zorro_esp_priv
>   pointers). Note: require esp pointer in zorro_esp_priv to find host
>   pointer!
> - back out phase bits changes to pio_cmd !write branch introduced
>   to cope with ESP SELAS command. We don't use that code so keep
>   it in sync with Finn's version.
> - use esp_ops.dma_length_limit() to limit transfer size. After review
>   of old driver code, use 0xff max transfer size throughout.
> 
> Fixed issues raised by Geert Uytterhoven:
> 
> - dynamically alloc zorro_private_data, store as device drvdata.
> - store ctrl_data for CyberStormI in driver private data.
> - use dma_sync_single_for_device() instead of cache_push/clear.
> - handle case of duplicate board identity - check whether board is
>   Zorro III or Zorro II (use ROM resource data for this). Also fix
>   up DMA mask for Zorro II boards to 32 bits (these are really CPU
>   expansion slot boards).
> - remove zorro3 field from driver_data struct (now in private data).
> - add braces around ambiguous if - else construct.
> - use named structs instead of array for board config data.
> - use scsi_option driver data flag for boards with optional ESP.
> 
> Other improvements and bugfixes
> 
> - fix Zorro device table error (duplicate ID used, also raised
>   by Kars de Jong).
> - error code fixup in error handling path.
> - add separate DMA setup for Blizzard 1230 II board.
> - add support for Cyberstorm II board.
> - add register structs and DMA setup for Zorro III Fastlane board,
>   following logic from old fastlane.c driver. Wire up Fastlane DMA
>   and interrupt status routines, map the necessary low 24 bit board
>   address space used for DMA target address setting. Clean up DMA
>   register space ioremap() branch for Zorro III boards (currently
>   Fastlane only) to end confusion about what to do in error recovery.
> - use esp_ops.fastlane_esp_dma_invalidate() on Fastlane (and skip
>   fastlane_esp_reset_dma() in DMA setup).
> - credit Tuomas Vainikka for contributing Blizzard 1230 code (and
>   testing).
> - clarify comment about unsupported Oktagon SCSI board.
> - remove unused const definitions carried over from old driver.
> 
> Changes since v2:
> 
> - add SPDX-License-Identifier.
> - remove unused ratelimit.h.
> - drop phys_to_virt() in PIO transfer routine, after ensuring PIO is only
>   used for message in transfers to esp->command_block. This obviates any
>   need for finding the virtual address corresponding to a DMA handle.
> - drop BUG_ON(!(cmd & ESP_CMD_DMA)) assertion in DMA setup. Short of changes
>   to the core ESP driver, this can never trigger.
> - make ioremap() of DMA address range conditional on zep->zorro3 and use
>   that same condition to unmap in error handling and driver exit.
>   Omit board ID test 

Re: [PATCH 09/14] lpfc: Fix driver not recovering NVME rports during target link faults

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:21 -0700
James Smart  wrote:

> During target-side port faults, the driver would not recover all
> target port logins. This resulted in a loss of nvme device discovery.
> 
> The driver is coded to wait for all GID_FT requests to complete
> before restarting discovery. A fault is seen where the outstanding
> GIT_FT counts are not properly decremented, thus discovery would
> never start. Another fault was found in the clearing of the gidft_inp
> counter that would be skipped in this condition. And a third fault
> found with lpfc_nvme_register_port that would remove a reverence
> on the ndlp which then allows a node swap on a port address change
> to prematurely remove the reference and release the ndlp.
> 
> The following changes are made:
> Correct the decrementing of the outstanding GID_FT counters.
> In RSCN handling, no longer zero the counter before calling to
>   issue another GID_FT.
> No longer remove the reference on the dlp when the ndlp->nrport
>   value is not yet null.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_ct.c   |  5 +
>  drivers/scsi/lpfc/lpfc_els.c  |  1 -
>  drivers/scsi/lpfc/lpfc_nvme.c | 12 ++--
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 08/14] lpfc: Fix WQ/CQ creation for older asic's.

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:20 -0700
James Smart  wrote:

> The patch to enlarge WQ/CQ creation keys off of an adapter
> response that indicates support for the larger values. Older
> adapters return an incorrect response and are limited in size.
> Thus the adapters fail the WQ creation steps.
> 
> Augment the WQ sizing checks with a check on the older adapter
> types and limit them to the restricted sizes.
> 
> Fixes: c176ffa0841c ("scsi: lpfc: Increase CQ and WQ sizes for SCSI")
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_hw4.h  | 12 
>  drivers/scsi/lpfc/lpfc_init.c | 15 +++
>  drivers/scsi/lpfc/lpfc_sli4.h |  1 +
>  3 files changed, 28 insertions(+)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 07/14] lpfc: Fix NULL pointer access in lpfc_nvme_info_show

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:19 -0700
James Smart  wrote:

> After making remoteport unregister requests, the ndlp nrport pointer
> was stale.
> 
> Track when waiting for waiting for unregister completion callback and
> adjust nldp pointer assignment.  Add a few safety checks for NULL
> pointer values.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_attr.c| 16 
>  drivers/scsi/lpfc/lpfc_debugfs.c |  8 ++--
>  drivers/scsi/lpfc/lpfc_nvme.c| 13 +
>  drivers/scsi/lpfc/lpfc_nvme.h|  4 
>  4 files changed, 31 insertions(+), 10 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 05/14] lpfc: Fix Abort request WQ selection

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:17 -0700
James Smart  wrote:

> When running loads that generated aborts, io errors where seen.
> Turns out the abort requests where not placed on the proper
> WQ resulting in the errors. Closer inspection inspection of this
> error also showed improper spinlock api use.
> 
> Correct the WQ selection policy for the abort requests.
> Correct spin_lock/spin_lock_irq/spin_lock_irqsave usage.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_scsi.c | 12 ++--
>  drivers/scsi/lpfc/lpfc_sli.c  | 14 +++---
>  2 files changed, 13 insertions(+), 13 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 06/14] lpfc: Fix lingering lpfc_wq resource after driver unload

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:18 -0700
James Smart  wrote:

> After driver unloads lpfc_wq remains active. The destroy_workqueue
> calls were not being made in driver unload.  Additionally, SLI3 is
> allocating lpfc_wq resources, but never uses it.
> 
> Make the destroy_workqueue calls on driver unload.
> Modify the SLI3 code path no longer allocate lpfc_wq resources.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc_init.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

Hannes



Re: [PATCH 04/14] lpfc: Enlarge nvmet asynchronous receive buffer counts

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:16 -0700
James Smart  wrote:

> Under large io load, the current sizing of asynchronous buffer counts
> could be exceeded, indicated by a 2885 log message:
>   2885 Port Status Event: port status reg 0x8180, port smphr
>   reg 0xc000, error 1=0x52004a01, error 2=0x0
> 
> Enlarge the async receive queue size.  Allow for a configurable number
> of buffers to be posted to each RQ, using the new attribute
> lpfc_nvmet_mrq_post.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc.h   |  1 +
>  drivers/scsi/lpfc/lpfc_attr.c  | 11 +++
>  drivers/scsi/lpfc/lpfc_nvmet.h |  6 --
>  drivers/scsi/lpfc/lpfc_sli.c   |  2 +-
>  4 files changed, 17 insertions(+), 3 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 03/14] lpfc: Add per io channel NVME IO statistics

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:15 -0700
James Smart  wrote:

> When debugging various issues, per IO channel IO statistics were
> useful to understand what was happening. However, many of the stats
> were on a port basis rather than an io channel basis.
> 
> Move statistics to an io channel basis.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc.h |   6 ---
>  drivers/scsi/lpfc/lpfc_attr.c|  40 +--
>  drivers/scsi/lpfc/lpfc_debugfs.c |  65 
>  drivers/scsi/lpfc/lpfc_init.c|  36 -
>  drivers/scsi/lpfc/lpfc_nvme.c| 107
> ++-
> drivers/scsi/lpfc/lpfc_nvme.h|  10  6 files changed, 173
> insertions(+), 91 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Re: [PATCH 02/14] lpfc: Correct target queue depth application changes

2018-04-09 Thread Hannes Reinecke
On Sat,  7 Apr 2018 11:30:14 -0700
James Smart  wrote:

> The max_scsicmpl_time parameter can be used to perform scsi cmd queue
> depth mgmt based on io completion time: the queue depth is reduced to
> make completion time shorter. However, as soon as an io completes and
> the completion time is within limits, the code immediately bumps the
> queue depth limit back up to the target queue depth. Thus the
> procedure restarts, effectively limiting the usefulness of adjusting
> queue depth to help completion time.
> 
> This patch makes the following changes:
> Removes the code at io completion that resets the queue depth as soon
>   as within limits.
> As the code removed was where the target queue depth was first
> applied, change target queue depth application so that it occurs when
> the parameter is changed.
> Makes target queue depth a standard parameter: both a module parameter
>   and a sysfs parameter.
> Optimizes the command pending count by using atomics rather than
> locks. Updates the debugfs nodelist stats to allow better debugging
> of pending command counts.
> 
> Signed-off-by: Dick Kennedy 
> Signed-off-by: James Smart 
> ---
>  drivers/scsi/lpfc/lpfc.h |  2 --
>  drivers/scsi/lpfc/lpfc_attr.c| 45
> ++--
> drivers/scsi/lpfc/lpfc_debugfs.c | 20 --
> drivers/scsi/lpfc/lpfc_scsi.c| 19 + 4 files
> changed, 66 insertions(+), 20 deletions(-)
> 

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes


Grüße von Frau Jordanka

2018-04-09 Thread noreply

Nachricht des Absenders:
/Guten Morgen,
Bitte schämen Sie sich nicht, diese Nachricht zu lesen, weil Sie der
beabsichtigte Empfänger sind. Ich habe deine E-Mail-Adresse über ein
Verzeichnis gesehen und ich habe dich kontaktiert, weil ich dringend deine
Hilfe benötigt habe. Mein Name ist Frau Yordanka Velikova Nencheva. Ich bin
69 Jahre alt und bin rechtmäßig mit dem verstorbenen Herrn Peter Nencheva
verheiratet. Ich und mein verstorbener Ehemann waren beide Bürger von
Bulgarien, aber wir lebten hier in der Elfenbeinküste in Westafrika seit 28
Jahren.
Mein verstorbener Ehemann arbeitete viele Jahre lang als Expatriate hier in
der Elfenbeinküste, bevor er bei einem tödlichen Autounfall starb, bei dem
er und sein Fahrer hier in der Elfenbeinküste ums Leben kamen. Ich und mein
verstorbener Mann waren beide verheiratet, ohne ein eigenes leibliches Kind.
Ich habe derzeit eine schwere Brustkrebskrankheit und schreibe diese
Nachricht mit Hilfe eines Arztes hier im Krankenhaus in der Elfenbeinküste.
Als mein verstorbener Ehemann noch am Leben war, hinterlegte er die Summe von
einer Million fünfhunderttausend Euro (1,500,000.00 Euro) bei der Westra
Wermlands Sparbank http://www.warbarbank.se/ in Schweden, die er mit der Bank
eine Vereinbarung unterzeichnete die Mittel werden für wohltätige Zwecke
verwendet, wie z. Hilfe für die mutterlosen Babys, Unterstützung der
kirchlichen Aktivitäten und Unterstützung der nicht privilegierten Kinder,
ihre Ausbildung fortzusetzen. Mein Mann hat diese Entscheidung für diese
karitative Arbeit getroffen, weil wir kein Kind haben, das die Gelder in der
schwedischen Bank erbt, und er wurde von einem Waisenhaus in Sofia,
Bulgarien, erzogen, weil er keine Familie in Bulgarien hat.
Ich kontaktierte Sie heute, weil mein Arzt mich gerade darüber informiert
hat, dass meine Brustkrebskrankheit am schlimmsten geworden ist und sie
nächste Woche eine schwere / tödliche Krebsoperation durchführen werden,
die ich vielleicht nicht überleben würde, weil der Tod tief in meinem
Körpersystem gefressen hat. Ich fürchte, wenn ich nächste Woche während
meiner Operation sterbe, werden die Gelder in der schwedischen Bank
vergessen, weil ich keinen anderen Verwandten habe, der behauptet, dass ich
keine Familie meines verstorbenen Ehemannes in Bulgarien finden kann.
Hinweis: Ich möchte, dass Sie mir helfen, das Geld auf Ihr eigenes Bankkonto
zu überweisen und es auf Ihr Bankkonto zu überweisen. Sie werden 30%
(450,000.00 Euro) des Gesamtbetrages für sich selbst als Entschädigung
einstreichen und die restlichen 70% (1,50, 000,00 Euro) für die
Wohltätigkeitsarbeit in Ihrem Land verwenden.
Bitte antworten Sie mir dringend, wenn Sie daran interessiert sind, mir bei
dieser Transaktion zu helfen, damit ich Ihnen weitere Einzelheiten zusenden
kann, da ich möchte, dass die Mittel vor meiner bevorstehenden Operation
nächste Woche überwiesen werden.
Mit freundlichen Grüßen,
Frau Yordanka Nencheva Velikova/
Parador de Alcañiz [1]

[1] http://www.parador.es/de/paradores/parador-de-alcaniz