Re: [PATCH] usb: storage: fix runtime pm issue in usb_stor_probe2
Am 03.08.2016 um 23:25 schrieb Alan Stern:
> On Wed, 3 Aug 2016, Heiner Kallweit wrote:
>
>> Since commit 71723f95463d "PM / runtime: print error when activating a
>> child to unactive parent" I see the following error message:
>>
>> scsi host2: usb-storage 1-3:1.0
>> scsi host2: runtime PM trying to activate child device host2 but parent
>> (1-3:1.0) is not active
>>
>> Digging into it it seems to be related to the problem described in the
>> commit message for cd998ded5c12 "i2c: designware: Prevent runtime
>> suspend during adapter registration" as scsi_add_host also calls
>> device_add and after the call to device_add the parent device is
>> suspended.
>>
>> Fix this by using the approach from the mentioned commit and getting
>> the runtime pm reference before calling scsi_add_host.
>
> Acked-by: Alan Stern
>
> There's nothing wrong with this patch; it's a worthwhile thing to do
> because it can prevent an unnecessary runtime-suspend/resume cycle.
>
> Still, it looks like the real problem here may lie in
> drivers/scsi/hosts.c. Commit bc4f24014de5 ("[SCSI] implement runtime
> Power Management") added a call to pm_runtime_set_active() in
> scsi_add_host_with_dma() _after_ device_add() instead of _before_.
>
> If that were changed, this problem would not have occurred.
>
In parallel to this patch I sent another one to address exactly the
ordering issue in scsi_add_host_with_dma you mention.
The other patch went to Martin and the SCSI mailing list only, sorry.
I'll forward it to you for review.
Heiner
> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] fcoe: use kfree_skb() to free an skb
On Thu, Aug 04, 2016 at 08:27:56AM +0300, Dan Carpenter wrote:
> This should be doing kfree_skb() instead of kfree().
>
> Fixes: 9a6cf881df02 ('fcoe: implement FIP VLAN responder')
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c b/drivers/scsi/fcoe/fcoe_ctlr.c
> index a569c65..dcf3653 100644
> --- a/drivers/scsi/fcoe/fcoe_ctlr.c
> +++ b/drivers/scsi/fcoe/fcoe_ctlr.c
> @@ -2923,7 +2923,7 @@ static int fcoe_ctlr_vlan_recv(struct fcoe_ctlr *fip,
> struct sk_buff *skb)
> mutex_unlock(&fip->ctlr_mutex);
>
> drop:
> - kfree(skb);
> + kfree_skb(skb);
> return rc;
> }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dan,
This was already sent by Wei Yongjun and is
https://patchwork.kernel.org/patch/9245273/. Should be queued in Martin's tree
already.
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] aacraid: prevent out-of-bounds access due to changing fip header sizes
In aacraid's ioctl_send_fib() we do two fetches from userspace, one the
get the fib header's size and one for the fib itself. Later we use the
size field from the second fetch to further process the fib. If for some
reason the size from the second fetch is different than from the first
fix, we may encounter an out-of-bounds access in aac_fib_send(). This was
reported in https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was
assigned CVE-2016-6480.
Reported-by: Pengfei Wang
Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)'
Cc: sta...@vger.kernel.org
Signed-off-by: Johannes Thumshirn
---
drivers/scsi/aacraid/commctrl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 4b3bb52..2d4acd1 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -118,6 +118,12 @@ static int ioctl_send_fib(struct aac_dev * dev, void
__user *arg)
goto cleanup;
}
+ if (size != le16_to_cpu(kfib->header.Size)
+ + sizeof(struct aac_fibhdr)) {
+ retval = -EINVAL;
+ goto cleanup;
+ }
+
if (kfib->header.Command == cpu_to_le16(TakeABreakPt)) {
aac_adapter_interrupt(dev);
/*
--
1.8.5.6
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
IB/isert: Return value of iser target transport handlers ignored by iscsi target
Hi, In iSER target during iwarp connection tear-down due to ping timeouts, the rdma queues are set to error state and subsequent queued iscsi session commands posted shall fail with corresponding errno returned by ib_post_send/recv. At this stage iser target handlers (Ex: isert_put_datain()) return the error to iscsci target, but these errors are not being handled by the iscsi target handlers(Ex: lio_queue_status()). -> While closing the session in case of ping timeouts, isert_close_connection()-> isert_wait_conn()->isert_wait4cmds() checks for the queued session commands and waits infinitely for command completion 'cmd_wait_comp' in target_wait_for_sess_cmds(). 'cmd_wait_comp' will be never complete as the kref on the session command is not derefed, due to which target_release_cmd_kref() is not called by kref_put(). Due to this, the older session is not cleared causing the next login negotiation to fail as the older session is still active(Older SID exists). [Query 1] If the return value of ib_post_send/recv() are handled to deref the corresponding queued session commands, the wait on cmd_wait_comp will be complete and clears off the session successfully. Is this the rightway to do it here? [Query 2] An extra deref is done in case of transport_status CMD_T_TAS in target_wait_for_sess_cmds(), can similar implementation be done for transport state CMD_T_FABRIC_STOP? Can someone shed some light on these aspects. Thanks in advance. Thanks, Bharat. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/22] libfc: Revisit kref handling
On Wed, Aug 03, 2016 at 03:13:01PM +0200, Hannes Reinecke wrote:
> The kref handling in fc_rport is a mess. This patch updates
> the kref handling according to the following rules:
>
> - Take a reference whenever scheduling a workqueue
> - Take a reference whenever an ELS command is send
> - Drop the reference at the end of the workqueue function
> - Drop the reference at the end of handling ELS replies
> - Take a reference when allocating an rport
> - Drop the reference when removing an rport
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/libfc/fc_rport.c | 134
> --
> 1 file changed, 103 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/scsi/libfc/fc_rport.c b/drivers/scsi/libfc/fc_rport.c
> index 93f5961..6a98bb8 100644
> --- a/drivers/scsi/libfc/fc_rport.c
> +++ b/drivers/scsi/libfc/fc_rport.c
> @@ -44,6 +44,17 @@
> * path this potential over-use of the mutex is acceptable.
> */
>
> +/*
> + * RPORT REFERENCE COUNTING
> + *
> + * A rport reference should be taken when:
> + * - a workqueue item is scheduled
> + * - an ELS request is send
> + * The reference should be dropped when:
> + * - the workqueue function has finished
> + * - the ELS response is handled
> + */
Please sync with the rules in the commit message.
> +
> #include
> #include
> #include
> @@ -242,6 +253,8 @@ static void fc_rport_state_enter(struct fc_rport_priv
> *rdata,
> /**
> * fc_rport_work() - Handler for remote port events in the rport_event_queue
> * @work: Handle to the remote port being dequeued
> + *
> + * Reference counting: drops kref on return
> */
> static void fc_rport_work(struct work_struct *work)
> {
> @@ -272,8 +285,10 @@ static void fc_rport_work(struct work_struct *work)
> kref_get(&rdata->kref);
> mutex_unlock(&rdata->rp_mutex);
>
> - if (!rport)
> + if (!rport) {
> + FC_RPORT_DBG(rdata, "No rport!\n");
If you're re-sending the series, this and the other added debug statements
might be better suited in '[PATCH 02/22] libfc: additional debugging messages'.
Otherwise
Acked-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/22] libfc: additional debugging messages
On Wed, Aug 03, 2016 at 03:13:02PM +0200, Hannes Reinecke wrote: > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/22] libfc: spurious I/O error under high load
On Wed, Aug 03, 2016 at 03:13:04PM +0200, Hannes Reinecke wrote: > If a command times out libfc is sending an REC, which also > might fail (due to frames being lost or something). > If no data has been transferred we can simply retry > the command, but the current code sets a state of FC_ERROR, > which then is being translated into DID_ERROR, resulting > in an I/O error. > So to handle this properly we need to set a separate > state FC_TRANS_RESET and mapping it onto DID_SOFT_RETRY. > > Signed-off-by: Hannes Reinecke > --- Can you try to get that message into one line? > case FC_HRD_ERROR: > FC_FCP_DBG(fsp, "Returning DID_NO_CONNECT to scsi-ml " > "due to FC_HRD_ERROR\n"); Otherwise: Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/22] libfc: Debug PRLI failures
On Wed, Aug 03, 2016 at 03:13:06PM +0200, Hannes Reinecke wrote: > The initial PRLI is errored out with these messages: > [ 5424.530686] host8: rport 001a1e: Received a PRLI accept > [ 5424.530687] host8: rport 001a1e: PRLI spp_flags = 0x0 > [ 5424.530688] host8: rport 001a1e: Error -131938289606656 in state PRLI, > retrying > > 'spp_flags=0' is decidedly dodgy, as we should always return a valid PRLI > state here. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/22] fcoe: filter out frames from invalid vlans
On Wed, Aug 03, 2016 at 03:13:07PM +0200, Hannes Reinecke wrote:
> ---
> drivers/scsi/fcoe/fcoe_ctlr.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/fcoe/fcoe_ctlr.c b/drivers/scsi/fcoe/fcoe_ctlr.c
> index 1d0bec6..e7a14aa 100644
> --- a/drivers/scsi/fcoe/fcoe_ctlr.c
> +++ b/drivers/scsi/fcoe/fcoe_ctlr.c
> @@ -2710,11 +2710,21 @@ static int fcoe_ctlr_vn_recv(struct fcoe_ctlr *fip,
> struct sk_buff *skb)
> struct fc_rport_priv rdata;
> struct fcoe_rport frport;
> } buf;
> - int rc;
> + int rc, vlan_id = 0;
>
> fiph = (struct fip_header *)skb->data;
> sub = fiph->fip_subcode;
>
> + if (fip->lp->vlan)
> + vlan_id = skb_vlan_tag_get_id(skb);
> +
> + if (vlan_id && vlan_id != fip->lp->vlan) {
> + LIBFCOE_FIP_DBG(fip, "vn_recv drop frame sub %x vlan %d\n",
> + sub, vlan_id);
> + rc = -EAGAIN;
> + goto drop;
> + }
> +
> rc = fcoe_ctlr_vn_parse(fip, skb, &buf.rdata);
> if (rc) {
> LIBFCOE_FIP_DBG(fip, "vn_recv vn_parse error %d\n", rc);
> --
> 1.8.5.6
-ENOSIGNEDOFF and while you're at it, can you give 1 or 2 lines why we need to
filter it out in the commit message.
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/22] fcoe: FIP debugging
On Wed, Aug 03, 2016 at 03:13:03PM +0200, Hannes Reinecke wrote: > Add additional statements for debugging FIP frames. > > Signed-off-by: Hannes Reinecke With Bart's comment addressed: Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/22] libfc: Do not attempt to login if the port is already started
On Wed, Aug 03, 2016 at 03:13:05PM +0200, Hannes Reinecke wrote: > When the port is already started we don't need to login; that > will only confuse the state machine. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/22] fcoe: make R_A_TOV and E_D_TOV configurable
On Wed, Aug 03, 2016 at 03:13:08PM +0200, Hannes Reinecke wrote: > The user might want to modify the values for R_A_TOV and E_D_TOV, > so add new module parameters 'e_d_tov' and 'r_a_tov' for the > 'fcoe' modules and allow to modify them via sysfs attributes. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/22] libfc: use configured lport R_A_TOV when sending exchange
On Wed, Aug 03, 2016 at 03:13:09PM +0200, Hannes Reinecke wrote: > We should be using the configured R_A_TOV value when sending the > exchange. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/22] libfc: use configured e_d_tov for remote port state retries
On Wed, Aug 03, 2016 at 03:13:10PM +0200, Hannes Reinecke wrote: > If fc_rport_error_retry() is attempting to retry the remote > port state we should be waiting for the configured e_d_tov > value rather than the default. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/22] libfc: don't fail sequence abort for completed exchanges
On Wed, Aug 03, 2016 at 03:13:12PM +0200, Hannes Reinecke wrote: > If a sequence should be aborted the exchange might already > be completed (eg if the response is still queued in the rx > queue), so this shouldn't considered as an error. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/22] libfc: use error code for fc_rport_error()
On Wed, Aug 03, 2016 at 03:13:14PM +0200, Hannes Reinecke wrote: > We only ever use the 'fp' argument for fc_rport_error() to > encapsulate the error code, so we can as well do away with that > and pass the error directly. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/22] libfc: do not overwrite DID_TIME_OUT status
On Wed, Aug 03, 2016 at 03:13:13PM +0200, Hannes Reinecke wrote: > When a command is aborted it might already have the DID_TIME_OUT > status set, so we shouldn't be overwriting that. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/22] libfc: frame alloc failure messages
On Wed, Aug 03, 2016 at 03:13:15PM +0200, Hannes Reinecke wrote: > --- > drivers/scsi/libfc/fc_exch.c | 41 + > 1 file changed, 33 insertions(+), 8 deletions(-) > Missing Signed-off-by... -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/22] libfc: Send LS_RJT responses on frame allocation failure
On Wed, Aug 03, 2016 at 03:13:17PM +0200, Hannes Reinecke wrote: > When we fail to allocate a frame we should be sending an LS_RJT > response and not just silently drop the frame altogether. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/22] libfc: don't advance state machine for incoming FLOGI
On Wed, Aug 03, 2016 at 03:13:18PM +0200, Hannes Reinecke wrote: > When we receive an FLOGI but have already sent our own we should > not advance the state machine but rather wait for our FLOGI to > return before continuing with PLOGI. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/22] libfc: Do not drop out-of-order frames
On Wed, Aug 03, 2016 at 03:13:20PM +0200, Hannes Reinecke wrote: > When receiving packets from the network we cannot guarantee any > frame ordering, so we should be receiving all valid frames and > let the upper layers deal with it. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/22] libfc: Implement RTV responder
On Wed, Aug 03, 2016 at 03:13:19PM +0200, Hannes Reinecke wrote: > The libfc stack generates an RTV request, so we should be implementing > an RTV responder, too. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/22] libfc: reset timeout on queue full
On Wed, Aug 03, 2016 at 03:13:21PM +0200, Hannes Reinecke wrote: > When we're receiving a timeout we should be checking for queue > full status; if there are still some packets pending we should > be resetting the counter to ensure we're not missing out any > packets which are still queued. > > Signed-off-by: Hannes Reinecke Maybe we can get the debug statements into one line, but anyways Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/22] fc: add missing ELS explanation values
On Wed, Aug 03, 2016 at 03:13:16PM +0200, Hannes Reinecke wrote: > Add missing ELS RJT explanation values from FC-LS3. > > Signed-off-by: Hannes Reinecke Acked-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/22] FCoE VN2VN fixes
On 08/03/16 06:13, Hannes Reinecke wrote: As usual, comments and reviews are welcome. Great work :-) Have you been testing these patches against the LIO FCoE target driver? In that case you might need to port the following patch to LIO, a patch that fixes a subtle data corruption issue: https://sourceforge.net/p/scst/svn/4969. Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aacraid / Adaptec 3805 - AAC: Host adapter dead -1
On Mon, Aug 01, 2016 at 11:42:24AM +0200, Piotr Szymaniak wrote: > Hi, (Sorry, for almost-topposting. Leaving below for reference.) As a followup to this thread - looking for answers here and there I've added intel_iommu=igfx_off (found at some thread with some other hardware mentioning Sandy Bridge) and it seems to work - just transfered 300 gigabytes of data to a testing array. On the other hand it still fills logs with those over and over every 10 seconds: AAC: Host adapter dead -1 I'm using Intel i5-2400 with Intel DQ67SW motherboard. I've also tried various Live Linux 64-bit distros: 1/2. Arch Bang (4.6.4-1-ARCH) and Ubuntu 16.04.1 (4.4.0-31-generic #50-Ubuntu) - prints errors every 10 seconds (afair didnt test if it works as I expected it doesnt) 3. Ubuntu 14.04 (4.4.0-15-generic #31-Ubuntu) - doesnt print errors, works Further help appreciated. linux-scsi@v.k.o please CC me as I'm not subscribed, thanks. Best regards, Piotr Szymaniak. > I have some issues with Adaptec 3805 and found that it could be related to > iommu as described here [1]. I've tried various (iommu=pt etc.) but nothing > seems to change the behaviour of the controller. Also tried the patch [2] from > Alex Williamson on top of 4.6.5. Controller seems to work fine (random r/w) > for > some hours under Windows 7 or (on the same machine) with Clonezilla. > > Every 10 seconds my dmesg fills with: > AAC: Host adapter dead -1 > > Not sure about the state now (as I tried rebuilding kernel with some more PCI > related options, various iommu lines in grub etc), but I could read the array > (dd if=controller of=/dev/null), but not write. With dd write, trying to make > fs or partition or whatever it ended with messages similar to this: > DMAR: DRHD: handling fault status reg 3 > DMAR: DMAR:[DMA Write] Request device [03:01.0] fault addr ffbb5000 > DMAR:[fault reason 02] Present bit in context entry is clear > > So I'm looking for your help. :) > > I'm using Gentoo Linux with vanilla kernel 4.6.5/4.7.0. > > grub: > kernel /boot/vmlinuz root=*cut* enable_mtrr_cleanup intel_iommu=on rw > vfio-pci.ids=1002:9460,1002:aa30,8086:1c26 > vfio_iommu_type1.allow_unsafe_interrupts=1 > > (vfio-pci.ids are GPU, GPU audio and USB for passthru to Windows VM) > > dmesg attached > > ~ # lspci -nnvs 03:0e.0 > 03:0e.0 RAID bus controller [0104]: Adaptec AAC-RAID [9005:0285] > Subsystem: Adaptec 3805 [9005:02bc] > Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 18 > Memory at fb80 (64-bit, non-prefetchable) [size=2M] > Expansion ROM at fba0 [disabled] [size=256K] > Capabilities: [c0] Power Management version 2 > Capabilities: [d0] MSI: Enable- Count=1/2 Maskable- 64bit+ > Capabilities: [e0] PCI-X non-bridge device > Kernel driver in use: aacraid > > > linux-scsi@vger.kernel.org please CC me as I'm not subscribed, thanks. > > Best regards, > Piotr Szymaniak. > > > [1] https://www.redhat.com/archives/vfio-users/2016-July/msg00046.html > [2] https://www.redhat.com/archives/vfio-users/2016-July/msg00063.html > [0.404887] pci :02:00.0: bridge window [mem 0xfb80-0xfbaf] > [0.404923] pci :02:00.2: PCI bridge to [bus 04] > [0.404964] pci :00:1c.0: PCI bridge to [bus 02-04] > [0.404991] pci :00:1c.0: bridge window [mem 0xfb80-0xfbaf] > [0.405026] pci :00:1c.6: PCI bridge to [bus 05] > [0.405052] pci :00:1c.6: bridge window [mem 0xfbc0-0xfbcf] > [0.405086] pci :00:1e.0: PCI bridge to [bus 06] > [0.405110] pci :00:1e.0: bridge window [io 0xd000-0xdfff] > [0.405139] pci :00:1e.0: bridge window [mem 0xfbb0-0xfbbf] > [0.405173] pci_bus :00: resource 4 [io 0x-0x03af window] > [0.405174] pci_bus :00: resource 5 [io 0x03e0-0x0cf7 window] > [0.405175] pci_bus :00: resource 6 [io 0x03b0-0x03df window] > [0.405176] pci_bus :00: resource 7 [io 0x0d00-0x window] > [0.405178] pci_bus :00: resource 8 [mem 0x000a-0x000b window] > [0.405179] pci_bus :00: resource 9 [mem 0x000c-0x000d window] > [0.405180] pci_bus :00: resource 10 [mem 0xbfa0-0x window] > [0.405181] pci_bus :01: resource 0 [io 0xe000-0xefff] > [0.405183] pci_bus :01: resource 1 [mem 0xfbd0-0xfbdf] > [0.405184] pci_bus :01: resource 2 [mem 0xd000-0xdfff 64bit > pref] > [0.405185] pci_bus :02: resource 1 [mem 0xfb80-0xfbaf] > [0.405186] pci_bus :03: resource 1 [mem 0xfb80-0xfbaf] > [0.405188] pci_bus :05: resource 1 [mem 0xfbc0-0xfbcf] > [0.405189] pci_bus :06: resource 0 [io 0xd000-0xdfff] > [0.405190] pci_bus :06: resource 1 [mem 0xfbb0-0xfbbf] > [0.405191] pci_bus :06: resource 4 [io 0x-0x03af window] > [0.405192] pci_bus :06: resource 5 [io 0x03e0-0x0cf7 window] > [
Re: [PATCH 37/45] drivers: use req op accessor
On Wed, Aug 03, 2016 at 07:30:29PM -0500, Shaun Tancheff wrote: > I think the translation in loop.c is suspicious here: > > "if use DIO && not (a flush_flag or discard_flag)" > should translate to: > "if use DIO && not ((a flush_flag) || op == discard)" > > But in the patch I read: > "if use DIO && ((not a flush_flag) || op == discard) > > Which would have DIO && discards follow the AIO path? Indeed. Sorry for missing out on your patch, I just sent a fix in reply to Dave's other report earlier which is pretty similar to yours. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dm-mq and end_clone_request()
On Wed, Aug 03 2016 at 12:55pm -0400, Bart Van Assche wrote: > On 08/02/2016 05:40 PM, Mike Snitzer wrote: > >But I asked you to run the v4.7 kernel patches I > >pointed to _without_ any of your debug patches. > > I need several patches to fix bugs that are not related to the > device mapper, e.g. "sched: Avoid that __wait_on_bit_lock() hangs" > (https://lkml.org/lkml/2016/8/3/289). OK, but you have way more changes than seem needed. In particular the blk-mq error handling changes look suspect. I'm also not sure what REQ_FAIL_IF_NO_PATH is all about (vaguely recall seeing it before; and suggesting you use SCSI's more traditional differentiated IO errors). Anyway, at this point you're having us test too many changes that aren't yet upstream: $ git diff bart/srp-initiator-for-next dm/dm-4.7-mpath-fixes -- drivers block include kernel | diffstat block/bio-integrity.c |1 block/blk-cgroup.c |4 block/blk-core.c| 16 --- block/blk-mq.c | 16 --- block/partition-generic.c |3 drivers/acpi/acpica/nswalk.c|1 drivers/infiniband/core/rw.c| 24 +++-- drivers/infiniband/core/verbs.c |9 -- drivers/infiniband/hw/hfi1/Kconfig |1 drivers/infiniband/hw/mlx4/qp.c |6 - drivers/infiniband/sw/rdmavt/Kconfig|1 drivers/infiniband/ulp/isert/ib_isert.c |2 drivers/infiniband/ulp/isert/ib_isert.h |1 drivers/infiniband/ulp/srp/ib_srp.c | 131 drivers/infiniband/ulp/srp/ib_srp.h |5 - drivers/infiniband/ulp/srpt/ib_srpt.c | 10 +- drivers/infiniband/ulp/srpt/ib_srpt.h |6 - drivers/md/dm-crypt.c |4 drivers/md/dm-ioctl.c | 77 +- drivers/md/dm-mpath.c | 32 --- drivers/md/dm.c | 22 - drivers/scsi/scsi_lib.c | 36 +--- drivers/scsi/scsi_priv.h|2 drivers/scsi/scsi_scan.c|2 drivers/scsi/scsi_sysfs.c | 48 --- drivers/scsi/sd.c |6 - drivers/scsi/sg.c |3 include/linux/blk-mq.h |3 include/linux/blk_types.h |5 - include/linux/blkdev.h |1 include/linux/dmar.h|2 include/rdma/ib_verbs.h |6 - include/scsi/scsi_device.h |2 kernel/sched/wait.c |2 34 files changed, 106 insertions(+), 384 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 37/45] drivers: use req op accessor
On Thu, Aug 4, 2016 at 10:46 AM, Christoph Hellwig wrote: > On Wed, Aug 03, 2016 at 07:30:29PM -0500, Shaun Tancheff wrote: >> I think the translation in loop.c is suspicious here: >> >> "if use DIO && not (a flush_flag or discard_flag)" >> should translate to: >> "if use DIO && not ((a flush_flag) || op == discard)" >> >> But in the patch I read: >> "if use DIO && ((not a flush_flag) || op == discard) >> >> Which would have DIO && discards follow the AIO path? > > Indeed. Sorry for missing out on your patch, I just sent a fix > in reply to Dave's other report earlier which is pretty similar to > yours. No worries. I prefer your switch to a an if conditional here. -- Shaun Tancheff -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi: core: configure runtime pm before calling device_add in scsi_add_host_with_dma
Am 03.08.2016 um 21:49 schrieb Heiner Kallweit: > Runtime PM should be configured already once we call device_add. See also > the description in this mail thread > https://lists.linuxfoundation.org/pipermail/linux-pm/2009-November/023198.html > or the order of calls e.g. in usb_new_device. > > The changed order also helps to avoid scenarios where runtime pm for > &shost->shost_gendev is activated whilst the parent is suspended, > resulting in error message "runtime PM trying to activate child device > hostx but parent yyy is not active". > > In addition properly reverse the runtime pm calls in the error path. > > Signed-off-by: Heiner Kallweit > --- > drivers/scsi/hosts.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c > index ba9af4a..9ab94ad 100644 > --- a/drivers/scsi/hosts.c > +++ b/drivers/scsi/hosts.c > @@ -246,10 +246,6 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, > struct device *dev, > > shost->dma_dev = dma_dev; > > - error = device_add(&shost->shost_gendev); > - if (error) > - goto out_destroy_freelist; > - > /* >* Increase usage count temporarily here so that calling >* scsi_autopm_put_host() will trigger runtime idle if there is > @@ -260,6 +256,10 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, > struct device *dev, > pm_runtime_enable(&shost->shost_gendev); > device_enable_async_suspend(&shost->shost_gendev); > > + error = device_add(&shost->shost_gendev); > + if (error) > + goto out_destroy_freelist; > + > scsi_host_set_state(shost, SHOST_RUNNING); > get_device(shost->shost_gendev.parent); > > @@ -309,6 +309,10 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost, > struct device *dev, > out_del_gendev: > device_del(&shost->shost_gendev); > out_destroy_freelist: > + device_disable_async_suspend(&shost->shost_gendev); > + pm_runtime_disable(&shost->shost_gendev); > + pm_runtime_set_suspended(&shost->shost_gendev); > + pm_runtime_put_noidle(&shost->shost_gendev); > scsi_destroy_command_freelist(shost); > out_destroy_tags: > if (shost_use_blk_mq(shost)) > Acked-by: Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dm-mq and end_clone_request()
On 08/04/2016 09:10 AM, Mike Snitzer wrote: Anyway, at this point you're having us test too many changes that aren't yet upstream: $ git diff bart/srp-initiator-for-next dm/dm-4.7-mpath-fixes -- drivers block include kernel | diffstat block/bio-integrity.c |1 block/blk-cgroup.c |4 block/blk-core.c| 16 --- block/blk-mq.c | 16 --- block/partition-generic.c |3 drivers/acpi/acpica/nswalk.c|1 drivers/infiniband/core/rw.c| 24 +++-- drivers/infiniband/core/verbs.c |9 -- drivers/infiniband/hw/hfi1/Kconfig |1 drivers/infiniband/hw/mlx4/qp.c |6 - drivers/infiniband/sw/rdmavt/Kconfig|1 drivers/infiniband/ulp/isert/ib_isert.c |2 drivers/infiniband/ulp/isert/ib_isert.h |1 drivers/infiniband/ulp/srp/ib_srp.c | 131 drivers/infiniband/ulp/srp/ib_srp.h |5 - drivers/infiniband/ulp/srpt/ib_srpt.c | 10 +- drivers/infiniband/ulp/srpt/ib_srpt.h |6 - drivers/md/dm-crypt.c |4 drivers/md/dm-ioctl.c | 77 +- drivers/md/dm-mpath.c | 32 --- drivers/md/dm.c | 22 - drivers/scsi/scsi_lib.c | 36 +--- drivers/scsi/scsi_priv.h|2 drivers/scsi/scsi_scan.c|2 drivers/scsi/scsi_sysfs.c | 48 --- drivers/scsi/sd.c |6 - drivers/scsi/sg.c |3 include/linux/blk-mq.h |3 include/linux/blk_types.h |5 - include/linux/blkdev.h |1 include/linux/dmar.h|2 include/rdma/ib_verbs.h |6 - include/scsi/scsi_device.h |2 kernel/sched/wait.c |2 34 files changed, 106 insertions(+), 384 deletions(-) Hello Mike, Most of the changes you are referring to either are already upstream, are expected to arrive in Linus' tree later this week or only add debugging pr_info() statements. The changes that either are already upstream or that are expected to be upstream soon are: $ for b in origin/master dledford-rdma/k.o/for-4.8-1 dledford-rdma/k.o/for-4.8-2; do git log v4.7..$b --author="Bart Van Assche" | grep ^commit -A4 | sed -n 's/^//p'; done block: Fix spelling in a source code comment dm ioctl: Simplify parameter buffer management code dm crypt: Fix sparse complaints block/blk-cgroup.c: Declare local symbols static block/bio-integrity.c: Add #include "blk.h" block/partition-generic.c: Remove a set-but-not-used variable IB/hfi1: Disable by default IB/rdmavt: Disable by default IB/isert: Remove an unused member variable IB/srpt: Simplify srpt_queue_response() IB/srpt: Limit the number of SG elements per work request IB/core, RDMA RW API: Do not exceed QP SGE send limit IB/core: Make rdma_rw_ctx_init() initialize all used fields Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dirty/Writeback fields in /proc/meminfo affected by 20d74bf29c
On Mon, 1 Aug 2016 04:36:28 +0200 Tomas Vondra wrote:
> Hi,
>
> While investigating a strange OOM issue on the 3.18.x branch (which
> turned out to be already fixed by 52c84a95), I've noticed a strange
> difference in Dirty/Writeback fields in /proc/meminfo depending on
> kernel version. I'm wondering whether this is expected ...
>
> I've bisected the change to 20d74bf29c, added in 3.18.22 (upstream
> commit 4f258a46):
>
> sd: Fix maximum I/O size for BLOCK_PC requests
>
> With /etc/sysctl.conf containing
>
> vm.dirty_background_bytes = 67108864
> vm.dirty_bytes = 1073741824
>
> a simple "dd" example writing 10GB file
>
> dd if=/dev/zero of=ssd.test.file bs=1M count=10240
>
> results in about this on 3.18.21:
>
> Dirty:740856 kB
> Writeback: 12400 kB
>
> but on 3.18.22:
>
> Dirty: 49244 kB
> Writeback:656396 kB
>
> I.e. it seems to revert the relationship. I haven't identified any
> performance impact, and apparently for random writes the behavior did
> not change at all (or at least I haven't managed to reproduce it).
>
> But it's unclear to me why setting a maximum I/O size should affect
> this, and perhaps it has impact that I don't see.
So what appears to be happening here is that background writeback is
cutting in earlier - the amount of pending writeback ("Dirty") is
reduced while the amount of active writeback ("Writeback") is
correspondingly increased.
4f258a46 had the effect of permitting larger requests into the request
queue. It's unclear to me why larger requests would cause background
writeback to cut in earlier - the writeback code doesn't even care
about individual request sizes, it only cares about aggregate pagecache
state.
Less Dirty and more Writeback isn't necessarily a bad thing at all, but
I don't like mysteries. cc linux-mm to see if anyone else can
spot-the-difference.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] aacraid: prevent out-of-bounds access due to changing fip header sizes
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Johannes Thumshirn
> Sent: Thursday, August 04, 2016 2:36 AM
> To: Martin K . Petersen; James Bottomley
> Cc: Linux SCSI Mailinglist; Pengfei Wang; Johannes Thumshirn;
> sta...@vger.kernel.org
> Subject: [PATCH] aacraid: prevent out-of-bounds access due to changing fip
> header sizes
>
> EXTERNAL EMAIL
>
>
> In aacraid's ioctl_send_fib() we do two fetches from userspace, one the get
> the
> fib header's size and one for the fib itself. Later we use the size field
> from the
> second fetch to further process the fib. If for some reason the size from the
> second fetch is different than from the first fix, we may encounter an out-of-
> bounds access in aac_fib_send(). This was reported in
> https://bugzilla.kernel.org/show_bug.cgi?id=116751 and was assigned CVE-
> 2016-6480.
>
> Reported-by: Pengfei Wang
> Fixes: 7c00ffa31 '[SCSI] 2.6 aacraid: Variable FIB size (updated patch)'
> Cc: sta...@vger.kernel.org
> Signed-off-by: Johannes Thumshirn
> ---
> drivers/scsi/aacraid/commctrl.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
> index 4b3bb52..2d4acd1 100644
> --- a/drivers/scsi/aacraid/commctrl.c
> +++ b/drivers/scsi/aacraid/commctrl.c
> @@ -118,6 +118,12 @@ static int ioctl_send_fib(struct aac_dev * dev, void
> __user *arg)
> goto cleanup;
> }
>
> + if (size != le16_to_cpu(kfib->header.Size)
> + + sizeof(struct aac_fibhdr)) {
> + retval = -EINVAL;
> + goto cleanup;
> + }
> +
> if (kfib->header.Command == cpu_to_le16(TakeABreakPt)) {
> aac_adapter_interrupt(dev);
> /*
> --
> 1.8.5.6
>
NAK, size is the MAX((header.size+hdr), sender_size). I will send a patch
tomorrow which will insure that neither of those values is larger than size on
the second fetch.
Thanks, -Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] scsi: fix upper bounds check of sense key in scsi_sense_key_string()
Commit 655ee63cf371 added a "Completed" sense string with key 0xF to
snstext[], but failed to updated the upper bounds check of the sense key in
scsi_sense_key_string().
Fixes: 655ee63cf371 ("[SCSI] scsi constants: command, sense key + additional
sense strings")
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/constants.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 83458f7..70d8dc4 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -362,7 +362,7 @@ static const char * const snstext[] = {
/* Get sense key string or NULL if not available */
const char *
scsi_sense_key_string(unsigned char key) {
- if (key <= 0xE)
+ if (key <= 0xF)
return snstext[key];
return NULL;
}
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] qla2xxx: small cleanup in qla2x00_wait_for_hba_ready()
On 8/3/16, 11:42 AM, "Dan Carpenter" wrote:
>The "if (test_bit(UNLOADING..." line was indented one tab more than it
>should have been. There was an extra parenthesis around the
>qla2x00_reset_active() function call. I lined up the conditions a bit
>so that it shows how they group together.
>
>Signed-off-by: Dan Carpenter
>
>diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
>index 2674f4c..1dd8650 100644
>--- a/drivers/scsi/qla2xxx/qla_os.c
>+++ b/drivers/scsi/qla2xxx/qla_os.c
>@@ -899,12 +899,12 @@ qla2x00_wait_for_hba_ready(scsi_qla_host_t *vha)
> struct qla_hw_data *ha = vha->hw;
> scsi_qla_host_t *base_vha = pci_get_drvdata(ha->pdev);
>
>- while (((qla2x00_reset_active(vha)) || ha->dpc_active ||
>- ha->flags.mbox_busy) ||
>- test_bit(FX00_RESET_RECOVERY, &vha->dpc_flags) ||
>- test_bit(FX00_TARGET_SCAN, &vha->dpc_flags)) {
>- if (test_bit(UNLOADING, &base_vha->dpc_flags))
>- break;
>+ while ((qla2x00_reset_active(vha) || ha->dpc_active ||
>+ ha->flags.mbox_busy) ||
>+ test_bit(FX00_RESET_RECOVERY, &vha->dpc_flags) ||
>+ test_bit(FX00_TARGET_SCAN, &vha->dpc_flags)) {
>+ if (test_bit(UNLOADING, &base_vha->dpc_flags))
>+ break;
> msleep(1000);
> }
> }
Looks Good.
Acked-by: Himanshu Madhani
>
Re: dm-mq and end_clone_request()
I've staged another fix, Laurence is seeing success with this added: https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.8&id=d50a6450104c237db1dc75314d17b78c990a8c05 I'll be sending all the fixes I've queued to Linus tonight or early tomorrow (since I'll then be on vacation until Monday 8/15). -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dm-mq and end_clone_request()
- Original Message - > From: "Mike Snitzer" > To: "Bart Van Assche" > Cc: dm-de...@redhat.com, "Laurence Oberman" , > linux-scsi@vger.kernel.org > Sent: Thursday, August 4, 2016 7:58:50 PM > Subject: Re: dm-mq and end_clone_request() > > I've staged another fix, Laurence is seeing success with this added: > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.8&id=d50a6450104c237db1dc75314d17b78c990a8c05 > > I'll be sending all the fixes I've queued to Linus tonight or early > tomorrow (since I'll then be on vacation until Monday 8/15). > Hello Bart, I applied that patch to your kernel and while I still obviously see all the debug logging its no longer failing fio for me. I ran 8 loops with 20 parallel fio runs. This was on a different server to the one I had been testing on. However I am concerned about timing playing a part here here so let us know what you find. Thanks Laurence -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 0/2] smartpqi: initial commit of Microsemi smartpqi driver
> "Don" == Don Brace writes: Don, Don> This driver is based on Linus's tree This initial commit contains Don> WIP of Microsemi's smartpqi module. Is your interface related to T10 PQI? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] fcoe: Use kfree_skb() instead of kfree()
> "Wei" == Wei Yongjun writes: Wei> Use kfree_skb() instead of kfree() to free sk_buff. Applied to 4.8/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated
> "Calvin" == Calvin Owens writes: Calvin> We blindly trust the hardware to give us NUL-terminated strings, Calvin> which is a bad idea because it doesn't always do that. For Calvin> example: Broadcom folks, please respond to this and other mpt3sas patches in the queue: https://patchwork.kernel.org/project/linux-scsi/list/?q=mpt3sas -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/28] be2iscsi: driver update 11.2.0.0
> "Jitendra" == Jitendra Bhivare writes: Somebody please review: https://patchwork.kernel.org/project/linux-scsi/list/?q=be2iscsi -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 2/3] mpt3sas: Eliminate dead sleep_flag code
With the exception of a single call to wait_for_doorbell_int(), all this
conditional sleeping code is dead. So delete it.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 241
+--
drivers/scsi/mpt3sas/mpt3sas_base.h | 6 +-
drivers/scsi/mpt3sas/mpt3sas_config.c| 3 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 15 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 21 +--
drivers/scsi/mpt3sas/mpt3sas_transport.c | 12 +-
6 files changed, 120 insertions(+), 178 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 751f13e..0956183 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -98,7 +98,7 @@ MODULE_PARM_DESC(mpt3sas_fwfault_debug,
" enable detection of firmware fault and halt firmware -
(default=0)");
static int
-_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_get_ioc_facts(struct MPT3SAS_ADAPTER *ioc);
/**
* _scsih_set_fwfault_debug - global setting of ioc->fwfault_debug.
@@ -218,8 +218,7 @@ _base_fault_reset_work(struct work_struct *work)
ioc->non_operational_loop = 0;
if ((doorbell & MPI2_IOC_STATE_MASK) !=
MPI2_IOC_STATE_OPERATIONAL) {
- rc = mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
- FORCE_BIG_HAMMER);
+ rc = mpt3sas_base_hard_reset_handler(ioc,
FORCE_BIG_HAMMER);
pr_warn(MPT3SAS_FMT "%s: hard reset: %s\n", ioc->name,
__func__, (rc == 0) ? "success" : "failed");
doorbell = mpt3sas_base_get_iocstate(ioc, 0); @@ -2145,7
+2144,7 @@ mpt3sas_base_map_resources(struct MPT3SAS_ADAPTER *ioc)
_base_mask_interrupts(ioc);
- r = _base_get_ioc_facts(ioc, CAN_SLEEP);
+ r = _base_get_ioc_facts(ioc);
if (r)
goto out_fail;
@@ -3172,12 +3171,11 @@ _base_release_memory_pools(struct MPT3SAS_ADAPTER
*ioc)
/**
* _base_allocate_memory_pools - allocate start of day memory pools
* @ioc: per adapter object
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 success, anything else error
*/
static int
-_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc, int sleep_flag)
+_base_allocate_memory_pools(struct MPT3SAS_ADAPTER *ioc)
{
struct mpt3sas_facts *facts;
u16 max_sge_elements;
@@ -3647,29 +3645,25 @@ mpt3sas_base_get_iocstate(struct MPT3SAS_ADAPTER
*ioc, int cooked)
* _base_wait_on_iocstate - waiting on a particular ioc state
* @ioc_state: controller state { READY, OPERATIONAL, or RESET }
* @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 for success, non-zero for failure.
*/
static int
-_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int
timeout,
- int sleep_flag)
+_base_wait_on_iocstate(struct MPT3SAS_ADAPTER *ioc, u32 ioc_state, int
+timeout)
{
u32 count, cntdn;
u32 current_state;
count = 0;
- cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+ cntdn = 1000 * timeout;
do {
current_state = mpt3sas_base_get_iocstate(ioc, 1);
if (current_state == ioc_state)
return 0;
if (count && current_state == MPI2_IOC_STATE_FAULT)
break;
- if (sleep_flag == CAN_SLEEP)
- usleep_range(1000, 1500);
- else
- udelay(500);
+
+ usleep_range(1000, 1500);
count++;
} while (--cntdn);
@@ -3681,24 +3675,22 @@ _base_wait_on_iocstate(struct MPT3SAS_ADAPTER
*ioc, u32 ioc_state, int timeout,
* a write to the doorbell)
* @ioc: per adapter object
* @timeout: timeout in second
- * @sleep_flag: CAN_SLEEP or NO_SLEEP
*
* Returns 0 for success, non-zero for failure.
*
* Notes: MPI2_HIS_IOC2SYS_DB_STATUS - set to one when IOC writes to
doorbell.
*/
static int
-_base_diag_reset(struct MPT3SAS_ADAPTER *ioc, int sleep_flag);
+_base_diag_reset(struct MPT3SAS_ADAPTER *ioc);
static int
-_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout,
- int sleep_flag)
+_base_wait_for_doorbell_int(struct MPT3SAS_ADAPTER *ioc, int timeout)
{
u32 cntdn, count;
u32 int_status;
count = 0;
- cntdn = (sleep_flag == CAN_SLEEP) ? 1000*timeout : 2000*timeout;
+ cntdn = 1000 * timeout;
do {
RE: [PATCH 1/3] mpt3sas: Eliminate conditional locking in mpt3sas_scsih_issue_tm()
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 1/3] mpt3sas: Eliminate conditional locking in
mpt3sas_scsih_issue_tm()
This flag that conditionally acquires the mutex is confusing and prone to
bugginess: refactor it into two separate function calls, and make the
unlocked one complain if it's called outside the mutex.
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 16 +++--
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 5 ++-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 66
+---
3 files changed, 38 insertions(+), 49 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index eb7f5b0..f0baafd 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -794,16 +794,6 @@ struct reply_post_struct {
dma_addr_t reply_post_free_dma;
};
-/**
- * enum mutex_type - task management mutex type
- * @TM_MUTEX_OFF: mutex is not required becuase calling function is
acquiring it
- * @TM_MUTEX_ON: mutex is required
- */
-enum mutex_type {
- TM_MUTEX_OFF = 0,
- TM_MUTEX_ON = 1,
-};
-
typedef void (*MPT3SAS_FLUSH_RUNNING_CMDS)(struct MPT3SAS_ADAPTER *ioc);
/**
* struct MPT3SAS_ADAPTER - per adapter struct @@ -1291,7 +1281,11 @@
void mpt3sas_scsih_reset_handler(struct MPT3SAS_ADAPTER *ioc, int
reset_phase);
int mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle,
uint channel, uint id, uint lun, u8 type, u16 smid_task,
- ulong timeout, enum mutex_type m_type);
+ ulong timeout);
+int mpt3sas_scsih_issue_locked_tm(struct MPT3SAS_ADAPTER *ioc, u16
handle,
+ uint channel, uint id, uint lun, u8 type, u16 smid_task,
+ ulong timeout);
+
void mpt3sas_scsih_set_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
void mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER *ioc, u16 handle);
void mpt3sas_expander_remove(struct MPT3SAS_ADAPTER *ioc, u64
sas_address); diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 7d00f09..75ae533 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -1001,10 +1001,9 @@ _ctl_do_mpt_command(struct MPT3SAS_ADAPTER *ioc,
struct mpt3_ioctl_command karg,
ioc->name,
le16_to_cpu(mpi_request->FunctionDependent1));
mpt3sas_halt_firmware(ioc);
- mpt3sas_scsih_issue_tm(ioc,
+ mpt3sas_scsih_issue_locked_tm(ioc,
le16_to_cpu(mpi_request->FunctionDependent1),
0, 0,
- 0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0,
30,
- TM_MUTEX_ON);
+ 0, MPI2_SCSITASKMGMT_TASKTYPE_TARGET_RESET, 0,
30);
} else
mpt3sas_base_hard_reset_handler(ioc, CAN_SLEEP,
FORCE_BIG_HAMMER);
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index acabe48..c93a7ba 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -2201,7 +2201,6 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER
*ioc, u16 handle)
* @type: MPI2_SCSITASKMGMT_TASKTYPE__XXX (defined in mpi2_init.h)
* @smid_task: smid assigned to the task
* @timeout: timeout in seconds
- * @m_type: TM_MUTEX_ON or TM_MUTEX_OFF
* Context: user
*
* A generic API for sending task management requests to firmware.
@@ -2212,8 +2211,7 @@ mpt3sas_scsih_clear_tm_flag(struct MPT3SAS_ADAPTER
*ioc, u16 handle)
*/
int
mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint
channel,
- uint id, uint lun, u8 type, u16 smid_task, ulong timeout,
- enum mutex_type m_type)
+ uint id, uint lun, u8 type, u16 smid_task, ulong timeout)
{
Mpi2SCSITaskManagementRequest_t *mpi_request;
Mpi2SCSITaskManagementReply_t *mpi_reply; @@ -2224,21 +,19 @@
mpt3sas_scsih_issue_tm(struct MPT3SAS_ADAPTER *ioc, u16 handle, uint
channel,
int rc;
u16 msix_task = 0;
- if (m_type == TM_MUTEX_ON)
- mutex_lock(&ioc->tm_cmds.mutex);
+ lockdep_assert_held(&ioc->tm_cmds.mutex);
+
if (ioc->tm_cmds.status != MPT3_CMD_NOT_USED) {
pr_info(MPT3SAS_FMT "%s: tm_cmd busy!!!\n",
__func__, ioc->name);
- rc = FAILED;
- goto err_out;
+ return FAILED;
}
if (ioc->shost_recovery || ioc->remove_host ||
ioc->pci_error_recover
RE: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: mpt-fusionlinux@broadcom.com
[mailto:mpt-fusionlinux@broadcom.com] On Behalf Of Calvin Owens
Sent: Friday, July 29, 2016 10:08 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH 3/3] mpt3sas: Fix warnings exposed by W=1
Trivial non-functional changes for a couple annoying things:
1) Functions local to files are not declared static, which is
frustrating when reading the code because it's non-obvious at first
glance what's actually called from other files.
2) Set-but-unused variables abound, presumably to mask -Wunused-result
errors in the past. None of these are flagged today though (with one
exception noted below), so remove them.
Fixing (2) exposed the fact that we improperly ignore the return value of
scsi_device_reprobe() in _scsih_reprobe_lun(). Fixing the calling code to
deal with the potential error is non-trivial, so for now just WARN().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.c | 18 +++-
drivers/scsi/mpt3sas/mpt3sas_config.c| 4 +-
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 29 ++---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 70
+++-
drivers/scsi/mpt3sas/mpt3sas_transport.c | 16 ++--
5 files changed, 56 insertions(+), 81 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 0956183..df95d1a 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -2039,7 +2039,7 @@ _base_enable_msix(struct MPT3SAS_ADAPTER *ioc)
* mpt3sas_base_unmap_resources - free controller resources
* @ioc: per adapter object
*/
-void
+static void
mpt3sas_base_unmap_resources(struct MPT3SAS_ADAPTER *ioc) {
struct pci_dev *pdev = ioc->pdev;
@@ -3884,7 +3884,6 @@ _base_handshake_req_reply_wait(struct
MPT3SAS_ADAPTER *ioc, int request_bytes,
MPI2DefaultReply_t *default_reply = (MPI2DefaultReply_t *)reply;
int i;
u8 failed;
- u16 dummy;
__le32 *mfp;
/* make sure doorbell is not in use */ @@ -3964,7 +3963,7 @@
_base_handshake_req_reply_wait(struct MPT3SAS_ADAPTER *ioc, int
request_bytes,
return -EFAULT;
}
if (i >= reply_bytes/2) /* overflow case */
- dummy = readl(&ioc->chip->Doorbell);
+ readl(&ioc->chip->Doorbell);
else
reply[i] = le16_to_cpu(readl(&ioc->chip->Doorbell)
& MPI2_DOORBELL_DATA_MASK);
@@ -4009,7 +4008,6 @@ mpt3sas_base_sas_iounit_control(struct
MPT3SAS_ADAPTER *ioc, {
u16 smid;
u32 ioc_state;
- unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4062,7 +4060,7 @@ mpt3sas_base_sas_iounit_control(struct
MPT3SAS_ADAPTER *ioc,
ioc->ioc_link_reset_in_progress = 1;
init_completion(&ioc->base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft = wait_for_completion_timeout(&ioc->base_cmds.done,
+ wait_for_completion_timeout(&ioc->base_cmds.done,
msecs_to_jiffies(1));
if ((mpi_request->Operation == MPI2_SAS_OP_PHY_HARD_RESET ||
mpi_request->Operation == MPI2_SAS_OP_PHY_LINK_RESET) && @@
-4112,7 +4110,6 @@ mpt3sas_base_scsi_enclosure_processor(struct
MPT3SAS_ADAPTER *ioc, {
u16 smid;
u32 ioc_state;
- unsigned long timeleft;
bool issue_reset = false;
int rc;
void *request;
@@ -4163,7 +4160,7 @@ mpt3sas_base_scsi_enclosure_processor(struct
MPT3SAS_ADAPTER *ioc,
memcpy(request, mpi_request, sizeof(Mpi2SepReply_t));
init_completion(&ioc->base_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft = wait_for_completion_timeout(&ioc->base_cmds.done,
+ wait_for_completion_timeout(&ioc->base_cmds.done,
msecs_to_jiffies(1));
if (!(ioc->base_cmds.status & MPT3_CMD_COMPLETE)) {
pr_err(MPT3SAS_FMT "%s: timeout\n",
@@ -4548,7 +4545,6 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
{
Mpi2PortEnableRequest_t *mpi_request;
Mpi2PortEnableReply_t *mpi_reply;
- unsigned long timeleft;
int r = 0;
u16 smid;
u16 ioc_status;
@@ -4576,8 +4572,7 @@ _base_send_port_enable(struct MPT3SAS_ADAPTER *ioc)
init_completion(&ioc->port_enable_cmds.done);
mpt3sas_base_put_smid_default(ioc, smid);
- timeleft =
wait_for_completion_timeout(&ioc->port_enable_cmds.done,
- 300*HZ);
+ wait_for_completion_timeout(&ioc->port_enable_cmds.done, 300*HZ);
if (
RE: [PATCH] mpt3sas: Ensure the connector_name string is NUL-terminated
Hi,
Please consider this patch as Acked-by: Chaitra P B
Thanks,
Chaitra
-Original Message-
From: Calvin Owens [mailto:calvinow...@fb.com]
Sent: Thursday, July 28, 2016 10:16 AM
To: Sathya Prakash; Chaitra P B; Suganath Prabu Subramani; James E.J.
Bottomley; Martin K. Petersen
Cc: mpt-fusionlinux@broadcom.com; linux-scsi@vger.kernel.org;
linux-ker...@vger.kernel.org; kernel-t...@fb.com; Calvin Owens
Subject: [PATCH] mpt3sas: Ensure the connector_name string is
NUL-terminated
We blindly trust the hardware to give us NUL-terminated strings, which is
a bad idea because it doesn't always do that. For example:
[ 481.184784] mpt3sas_cm0: enclosure level(0x), connector name(
\x3)
In this case, connector_name is four spaces. We got lucky here because the
2nd byte beyond our character array happens to be a NUL. Fix this by
explicitly writing '\0' to the end of the string to ensure we don't run
off the edge of the world in printk().
Signed-off-by: Calvin Owens
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 10 ++
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/scsi/mpt3sas/mpt3sas_base.h
index 892c9be..eb7f5b0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.h
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.h
@@ -478,7 +478,7 @@ struct _sas_device {
u8 pfa_led_on;
u8 pend_sas_rphy_add;
u8 enclosure_level;
- u8 connector_name[4];
+ u8 connector_name[5];
struct kref refcount;
};
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
index cd91a68..acabe48 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
@@ -5380,8 +5380,9 @@ _scsih_check_device(struct MPT3SAS_ADAPTER *ioc,
MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
- memcpy(&sas_device->connector_name[0],
- &sas_device_pg0.ConnectorName[0], 4);
+ memcpy(sas_device->connector_name,
+ sas_device_pg0.ConnectorName, 4);
+ sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0'; @@ -5508,8
+5509,9 @@ _scsih_add_device(struct MPT3SAS_ADAPTER *ioc, u16 handle, u8
phy_num,
if (sas_device_pg0.Flags &
MPI2_SAS_DEVICE0_FLAGS_ENCL_LEVEL_VALID) {
sas_device->enclosure_level =
le16_to_cpu(sas_device_pg0.EnclosureLevel);
- memcpy(&sas_device->connector_name[0],
- &sas_device_pg0.ConnectorName[0], 4);
+ memcpy(sas_device->connector_name,
+ sas_device_pg0.ConnectorName, 4);
+ sas_device->connector_name[4] = '\0';
} else {
sas_device->enclosure_level = 0;
sas_device->connector_name[0] = '\0';
--
2.8.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] mpt3sas: Don't spam logs if logging level is 0
Hi, Please consider this patch as Acked-by: Chaitra P B Thanks, Chaitra -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Johannes Thumshirn Sent: Wednesday, August 03, 2016 6:30 PM To: Martin K . Petersen; James Bottomley Cc: Linux SCSI Mailinglist; Linux Kernel Mailinglist; Sreekanth Reddy; Johannes Thumshirn Subject: [PATCH] mpt3sas: Don't spam logs if logging level is 0 In _scsih_io_done() we test if the ioc->logging_level does _not_ have the MPT_DEBUG_REPLY bit set and if it hasn't we print the debug messages. This unfortunately is the wrong way around. Note, the actual bug is older than af0094115 but this commit removed the CONFIG_SCSI_MPT3SAS_LOGGING Kconfig option which hid the bug. Fixes: af0094115 'mpt2sas, mpt3sas: Remove SCSI_MPTXSAS_LOGGING entry from Kconfig' Signed-off-by: Johannes Thumshirn --- drivers/scsi/mpt3sas/mpt3sas_scsih.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index 4a1cc85..a138690 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -4693,7 +4693,7 @@ _scsih_io_done(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 msix_index, u32 reply) le16_to_cpu(mpi_reply->DevHandle)); mpt3sas_trigger_scsi(ioc, data.skey, data.asc, data.ascq); - if (!(ioc->logging_level & MPT_DEBUG_REPLY) && + if ((ioc->logging_level & MPT_DEBUG_REPLY) && ((scmd->sense_buffer[2] == UNIT_ATTENTION) || (scmd->sense_buffer[2] == MEDIUM_ERROR) || (scmd->sense_buffer[2] == HARDWARE_ERROR))) -- 1.8.5.6 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
